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ABSTRACT 

The  paper  Investigates  methods  for  applying  an  on-line  Interactive  verification  system  designed  to 
prove  properties  of  PASCAL  programs.  The  methodology  is  intended  to  provide  techniques  for 
developing  a debugged  and  verified  version  starting  from  a program,  that  (a)  is  possibly 
unfinished  In  some  respects,  (b)  may  not  satisfy  the  given  specifications,  eg.,  may  contain  bugs, 
(c)  may  have  incomplete  documentation,  (d)  may  be  wrltter  in  non-standard  ways,  eg.,  may 
depend  on  user-  defined  data  structures. 

The  methodology  involves  (I)  Interactive  application  of  a verification  condition  generator,  an 
algebraic  simplifier  and  a theorem-prover;  (ii)  techniques  for  describing  data  structures,  type 
constraints,  and  properties  of  programs  and  subprograms  (i.e.  lower  level  procedures),  (III)  the 
use  of  (abstract)  data  types  in  structuring  programs  and  proofs. 

Within  each  unit  (i.e  segment  of  a problem),  the  interactive  use  !s  aimed  2t  reducing  verification 
conditions  to  manageable  proportions  so  hat  the  non-trivial  factors  may  be  analysed.  Analysis  of 
verification  conditions  attempts  to  localiz  e errors  in  the  program  logic,  to  extend  assertions  inside 
the  program,  to  spotlight  additional  assumptions  on  program  subfunctions  (beyond  those  already 
specified  by  the  programmer),  and  to  generate  appropriate  lemmas  that  allow  a verification  to  be 
completed.  Methods  for  structuring  correctness  proofs  are  discussed  that  are  similar  to  those  of 
’’structured  programming" 

A detailed  case  study  of  a pattern  matching  algorithm  illustrating  the  various  aspects  of  the 
methodology  (including  the  role  played  by  the  user)  is  given. 
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INTRODUCTION 


A METHODOLOGY  FOR  VERIFYING  PROGRAMS 
I INTROD  JCTION 

We  are  concerned  here  with  the  question  of  whether  or  not  program  verification  systems  that  are 
currently  heing  developed  have  any  practical  usefulness  Verifications  of  simple  standard 
programs  have  been  obtained  with  these  systems  (See  for  example,  [King  and  Floyd], 
[Igarashi  I -ndon  and  Luckham],  [Deutsch],  [Coed  and  Ragland],  [Flspas,  Levitt, and  Waldin^er]! 
[Suzuki],  [Boyer  and  Moore])  These  lesults  provide  encouragement  to  explore  further  But,  in 
all  cases  except  foi  one  example  in  [Morales]  the  programs  were  rnown  in  advance  to  be  correct 
- i e provably  consistent  with  their  documentation  Moieover,  these  example  test  programs  are 
based  on  standard  well  known  functions  and  data  structures  (for  the  most  part,  either  integer 
arithmetic  or  veiy  simple  list  processing).  Realistically  practical  verification  problems  have  ycr  to 
be  faced.  A methodology  for  using  these  systems  to  construct  verifications  in  real  life  situations  has 
not  been  developed,  and  indeed  the  question  of  whether  the;  will  help  the  process  of  writing  and 
verifying  programs  or  will  merely  “get  in  the  way"  is  entirely  open. 

The  goal  ot  practical  u etulness  does  not  imply  that  '.he  verification  of  a program  must  be  made 
independent  of  creative  effort  on  the  part  of  the  programmer  As  we  shall  see  later,  such  a 
lequirement  is  utterly  unrealistic  What  we  have  to  do  is  to  provide  a tool  (the  verification 
system)  and  instructions  for  its  use  (the  methodology)  that  can  sometimes  enable  a programmer  to 
gain  a degree  of  certainty  about  his  or  other  people’s  programs  The  tool  and  methods  must  be 
easy  to  apply  In  short,  we  seek  to  extend  the  programmer’s  repertoire  of  techniques,  not  to 
replace  it 

The  verification  system  discussed  here  has  beer  developed  specifically  for  programs  written  in 
PASCAL  [Wirth]  and  is  an  extension  (see  [Suzuki])  of  the  system  described  in  [ILL]  The 
purpose  of  this  system  is  to  aid  the  progiammer  in  constructing  a proof  that  his  program  satisfies 
its  documentation.  Such  a proof  (in  the  logic  of  programs  [Hoare  71,  ILL])  is  called  a verification 
of  the  program  The  oocumentao  n may  include 

1 input-output  specifications, 

2 properties  of  certain  crucial  internal  states, 

? specifications  and  properties  of  sub  programs, 

4 specifications  of  data  structuies. 

In  order  to  be  useful  in  practice  we  must  develop  a methodology  for  using  the  verifier  which  aids 
the  usei  in  situations  where 

1 the  documentation  is  incomplete  (re  additional  facts  about  the  program  must  be 
discovered  before  a venfication  can  be  found), 

2 the  program  itself  is  unfinished  (eg  p..,’s  of  it  may  be  unwutten), 

7 the  program  is  badly  written  (even  though  it  conforms  to  structuring  principles), 

4 the  data  r-'riictures  are  non  standard  (eg  an  axiomatic  desertion  does  not  already  exist). 

What  "aid"  should  one  expect  fiom  a verification  system?  A verification  proof  depends  upon  a set 
of  assumptions  or  lemmas  about  components  of  the  program  (sub-procedures,  data  structures, 
library  routines,  etc ).  Let  us  call  this  a BASIS  for  a verification  Essentially,  a verification  basis  is 
a set  of  consequences  of  an  underlying  axiom  itization  of  the  data  structures  and  subroutines, 
although  such  an  axiomatization  may  not  actually  be  known.  Different  proofs  have  different  bast:' 
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A verification  is  convincing  to  a programmer  only  if  he  "believes"  the  basis  in  the  rather 
imprecise  sense  that  its  statements  seem  true;  a more  precise  sense  (acceptable)  is  given  below.  As 
we  shall  show  in  examples,  a programmer  can  obtain  a verification  of  his  r,rogram  using  a 
verifier,  and  be  faced  with  an  impressively  complex  basis,  (or  even  worse,  with  some  systems  he 
might  end  up  without  knowing  the  basis  at  all)  If  he  does  not  believe  the  basis,  he  must  be  able 
to  reduce  its  elements  to  moie  believable  statements  or  else  search  for  an  alternative  basis.  Thus 
verification  methodology  must 

I establish  that  .»  basis  is  adequate,  (i.e.  ensure  the  existence  of  a corrrectness  proof  from  the 
basis), 

2.  present  alternative  bases  to  the  programmer,  (i.e,  help  him  discover  bases  and  improve 
documentation), 

3 include  methods  for  analyzing  a basis  and  reducing  its  components  to  other  bases. 

There  is  an  underlying  motivational  assumption  here  in  dealing  with  real  life  problems  it  may 
often  be  unrealistic  and  impractical  to  attempt  a verification  directly  from  first  principles.  It  is 
sufficient  to  establish  a verification  basis  that  is  clearly  implied  by  an  axiomatic  semantics  for 
those  concepts  that  are  used  in  the  program 

However,  in  the  case  of  a “new"  program  s,  h semantics  may  not  have  been  formulated. 
Consequently,  we  need  a methodology  which  permits  a verification  to  proceed  by  developing  a 
hierarchy  of  bases  in  which  a basis  at  one  level  verifies  elements  of  the  basis  immediately  above  it 
and  depends  on  bases  at  the  level  immediately  below.  The  development  of  this  hierarchy  can  be 
viewed  as  "discovering"  the  semantics;  it  will  usually  be  guided  by  the  structure  of  the  program.  A 
basis  for  verifying  properties  of  one  level  of  the  program  will  be  formulated  in  terms  of  concepts 
used  in  writing  that  level  The  statements  in  the  lowest  level  bases  should  be  already  established 
facts  (about  nonprimitives)  or  axioms  for  the  semantics  of  primitive  functions  and  data  structures. 
Apart  from  the  practical  need  to  divide  complicated  verifications  into  subproofs  which  may  be 
attempted  individually,  this  hierarchical  idea  has  other  advantages.  It  allows  a verification  to 
proceed  hand-in-hand  with  the  writing  of  the  program  A basis  is  to  be  viewed  as  more  than  just 
a set  of  assumptions  for  a verification  Often  it  includes  additional  necessary  properties  of 
unwritten  subroutines  beyond  what  was  in  their  original  specifications.  Alternatively,  the  omission 
of  a specification  might  indicate  that  a simpler  subioutine  will  suffice  Thus,  a basis  for  one  level 
of  a program  is  a sufficient  set  ol  specifications  for  the  next  level.  Secondly,  if  an  axiomatic 
semantics  for  new  concepts  is  needed,  it  is  probably  best  developed  from  a knowledge  of  adequate 
verification  bases  (consisting  of  simple  statements)  for  programs  using  those  concepts  Thirdly,  the 
problem  of  getting  differing  programmers  to  agree  upon  a "verification"  of  a program  can  be 
terminated  short  of  a complete  reduction  of  the  problem  to  first  principles  if  they  both  have 
confidence  in  the  acceptability  of  some  intermediate  basis. 

At  rh is  point  we  can  be  a little  more  precise  about  some  of  the  concepts  we  have  introduced: 

A s;t  of  statements  forms  a basis  for  verifying  a property  of  a program  if  a proof  of  that 
property  can  be  given  within  the  logic  uf  programs  [Hoare  71,  ILL]  which  assumes  (I.e  depends 
upon)  only  those  statements  For  emphasis,  we  shall  sometimes  say  that  such  a basis  is 

adequate 

A basis  is  acceptable  if  (i)  all  of  its  statements  about  the  primitives  (dr.ta  structures  and 
library  routines)  are  true,  and  (ii)  programs  can  be  constructed  to  satisfy  all  of  those  statements 
that  contain  names  for  uncoded  subroutines. 
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The  primary  problem  is  to  find  acceptable  verification  bares.  There  are  a number  of  important 
secondary  problems  The<e  can  ill  be  categorized  as  parts  of  the  "Formalization  problem"  First 
there  is  the  question  of  what  documentation  to  include  with  the  program;  for  example  which 
internal  states  need  to  hr  descnb'  d,  which  invariant  properties  of  a loop  need  to  be  stated  and 
what  properties  ot  subroutines  are  actually  necessary.  Secondly,  how  should  the  documentation 
be  expressed’  This  involves  the  choice  of  representation  of  concepts  (eg  should  the  relation  ” c " 
on  the  integers  be  used  o.  can  all  the  necessary  facts  be  expressed  in  terms  of  a derived  concent 
like  •$  ORDER fD  SET"’).  Also  the  programmer  must  choose  whether  to  express  internal 
propei ties  of  the  program  by  purely  "static"  assertions  about  the  values  of  its  variables  or  by 
defining  ext. a computations  and  making  assertions  about  new  -'ambles  (ie  the  technique  of 
introducing  "ghost"  variables  and  "virtual"  program  [Clint])  Thirdly,  how  should  the  program 
be  written  in  order  to  make  its  ver.hcat.on  possible  Recent  developments  in  programming 
language  design,  pietty  much  resulting  from  experience  with  the  debugging  problem,  such  as 
block  structure  and  restrictions  on  procedure  parameters  and  global  variables,  all  certainly  help 
However,  many  other  details  in  a program  influence  its  verification  (e.g.  the  form  of  data  structure 
definitions  should  indicate  clearly  the  assumptions  that  can  be  made  about  the  structures).  At  the 
moment,  these  secondary  problems  are  areas  where  the  programmer's  Ingenuity  must  be  applied 
It  is  to  be  hoped  that  verification  methodology  will  eventually  develop  some  relevant  guidelines 
for  attacking  the  formalization  problem.  6 

Our  methodology  can  be  very  roughly  outlined  as  follows.  A program  level,  which  may  contain 
calls  to  uncoded  lower  level  subi online*,  >s  submitted  together  with  some  documentation  to  the 
verification  system  The  general  methodology  divides  activity  into  three  phases  debugging  the 
code,  constructing  inductive  assertions,  and  constructing  a basis  . At  each  of  these  phases  the 
s>stem  Is  used  to  indicate  modifications  and  changes  by  means  of  a methodology  depending  on 
a ii r. lysis  of  verification  conditions  (see  Section  2.4).  (Eventually  we  Intend  to  incorporate  other 
techniques  for  analysing  programs)  Modified  problems  are  resubmittpd  for  further  analysis  In 
the  third  phase  the  system  prov.des  a test  for  the  adequacy  of  a proposed  basis.  Finally,  the  basis 
must  be  shown  to  be  acceptable,  which  involves  writing  the  next  level  of  the  program. 

We  shall  show  in  Section  3 how  the  Pascal  Verifier  can  be  used  interactively  to  verify  leve's  in  a 
program  as  they  are  written  and  to  guide  writing  subsequent  levels  We  illustrate  the 
methodology  in  act.cn  in  an  expenment  to  write  and  verify  a program  for  a fundamental  pattern 
matching  algorithm  (Unification)  We  have  tried  to  keep  our  presentation  as  dose  to  the  real  life 
sequence  of  events  as  possible  without  too  much  repetition.  Essentially,  we  present  snap<hots  of 
this  sequence  of  events,  each  snapshot  illustrating  a different  situation  which  the  methodology 
must  handle  Theie  are  examples  of  the  use  of  the  verifier  to  find  bugs,  to  augment 
documentation,  to  build  up  a basis,  and  to  analyze  the  basis  (i.e  reduce  It  to  simpler  statements). 
This  last  point  involves  choosing  a formalism  for  defining  recursive  data  structures,  and  here  we 
have  adopted  with  minor  modifications  some  suggestions  of  [Hoare  73],  Of  course,  our 
methodology  is  far  from  complete,  and  man)  of  the  problems  that  arise  during  a verification 
(except  for  the  adequacy  of  a basis,  which  i<  handled  automatically  by  the  system)  Involve  the 
user  in  making  choices  and  decisions.  It  ,s  already  clear  how  to  automate  some  of  this  work 

However,  we  must  emphasize  that  the  verifier  is  intended  for  use  in  conjunction  with  other 
programming  facilities  . J 

Some  parts  of  the  general  methodology  depend  on  a knowledge  of  what  the  components  of  the 
verifier  do.  We  have,  ther  fore,  included  a brief  description  of  the  verifier  in  Section  2 together 
with  a simple  example  ot  its  use  ° 


Tle  principle  references  upon  which  this  paper  depends  are  [Hoare  71]  and  [ILL]  (for  the  logic 


programs),  [Hoare  and  Wirth]  (for  axiomatic  semantics  of  Pascal),  ano  [ILL]  and  [Suzuki]  (for 
details  of  the  verifier)  We  shall  use  concepts  and  notation  from  [Hoare  71  ILL]  without  definition. 


2.  THE  VERIFIER 


The  Pascal  verification  system  is  represented  in  outline  in  Figure  I.  The  logical  theory  and 
implementation  of  the  Verification  Condition  Generator  (VCG)  is  given  In  [ILL],  and  details  of 
the  simplifier  are  In  [Suzuki]  In  section  3 we  shall  describe  interactive  use  of  this  system  that 
relies  mainly  on  these  two  components  and,  at  the  moment,  only  employs  the  theorem  prover  when 
everything  else  falls  Here  we  give  a very  brief  sketch  of  VCG  and  the  simplifier  with  the 
intention  of  mentioning  just  those  details  that  affect  the  methodology  of  Section  3. 
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Figure  I:  Main  Components  of  the  Verifier 


2.1  VERIFICATION  CONDITION  GENERATOR  (VCG)  The  input  to  VCG  Is  a verification 
problem  of  the  form  P{A)0  where  P and  Q_are  entry  and  exit  specifications  (called  assertions)  for 
a Pascal  piogiam  A The  progiam  A may  it'elf  contain  additional  documentation  Figure  2 
shows  an  input  to  VCG  together  with  some  extra  documentation  (explained  later)  To  verify  that 
A satisfies  its  specifications,  we  require  that  a proof  of  PjA}(^  within  the  logic  of  programs  be 
found  VCG  reduces  problems  of  the  form  P!A)Q.to  problems  about  shorter  programs,  using  the 
rule'  of  the  axiomatic  semantics  of  Pascal  For  example,  PjlF  L THEN  B ELSE  CJQ,  could  be 
reduced  to  verifying  two  problems.  PaL|BJ<^  and  Pa'L|C}C>,  the  axiomatic  semantics  for 
conditional  statements  implies  that  if  these  latter  two  problems  are  verified  then  the  first  problem 
is  also  verified.  Similar  reductions  are  applied  to  other  kinds  of  Pascal  statements.  The  final 
output  rom  VCG  is  a set  of  purely  logical  statements  composed  from  Pascal  Boolean  assertions 
(see  Figure  3)  These  are  called  the  Verification  Conditions  (abbreviated  to  VC’s)  for  the  original 
problem,  PjAJQ, 
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There  are  two  points  to  be  mentioned  here.  First  of  all,  VCC  has  a completeness  property  with 
respect  to  provability  Assume  that  a verification  of  P{A}Q,  is  to  be  found  making  only 
assumptions  from  some  underlying  axiomatic  semantics,  T say  A proof  of  P{A}Q,can  always  be 
constructed  assuming  the  VC’s,  and  conversely  if  PfAjQIs  provable  in  the  logic  of  programs 
from  T,  then  VC.C  will  generate  VC's  that  are  provable  in  T provided  A contains  additional 
helpful  assertions  (exactly  what  extra  documentation  must  be  given  is  a subject  of  much  current 
research)  This  means  that  the  set  of  VC’s  is  always  an  adequate  Basis  for  the  verification  (but  it 
may  not  be  acceptable)  And  also,  if  the  user’s  problem  is  provable  from  statements  In  T,  he  will 
be  able  to  establish  that  fact  with  the  present  verifier  by  adding  enough  documentation  to  the 
program.  The  second  point  is  that  VCG  reduces  problems  to  purely  logical  VC’s  As  we  shall  see 
later,  this  may  not  always  be  the  best  stra’egy,  especially  when  the  VC’s  involve  the  names  of 
procedures  that  have  yet  to  be  written,  and  it  may  sometimes  be  better  to  stop  the  reduction 
process  and  generate  VC’s  that  contain  pieces  of  code  explicitly.  It  is  doubtful  if  verification  can 
be  based  solely  on  pure  logic,  and  it  may  be  necessary  to  use  other  techniques  such  as  equivalence 
preserving  transformations  on  progiams 

Finally,  the  present  version  of  VCG  contains  a number  of  new  features  and  rules  that  are  not  in 
the  original  version  in  [ILL]  The  one  most  relevant  to  our  discussion  is  a feature  (due  to  Suzuki) 
for  handling  calls  to  uncoded  functions  by  means  of  "DEFFUN"  statements.  The  Intention  is  to 
give  the  user  an  easy  way  to  state  specifications  for  functions  that  are  not  yet  coded,  although  it 
can  be  used  for  standard  functions  as  well  A DEFFUN  statement  is  of  the  form: 

DEFFUN  f(x  I type  I,..  ):  type 

ENTRY  R(x  1 ,...);  EXIT  <Value>:S(f); 

where  "f"  is  the  function  name,  <value>  is  an  expression  denoting  the  value  of  f,  and  R(xl,...)  tmd 
S(xl,...)  are  entry  and  exit  assertions.  No  function  body  is  required.  Whenever  a call  to  f occurs 
during  the  generation  of  VC’s  the  adaptation  rule  [Hoare]  will  be  apolied. 

P{A)(R(a,...)  a V(a’,...XS(f(a\...))^f(a\...))) 


P{A;x«-f(a„..)JQ(x) 


A verification  of  the  program  will  then  imply  the  runtime  legality  of  all  calls  to  f.  The  use  of 
DEFFUN’S  is  not  mandatory,  and  the  user  may  choose  to  omit  them  If  he  is  sure  that  all  his 
function  calls  are  legal  (a  normal  compile-time  type  check  may  be  sufficient). 


2.2  THE  SIMPLIFIER  Many  VC’s  are  (or  contain  subformulas  that  are)  lengthy  and 
complicated  but  turn  out  to  be  logically  trivial.  The  first  step  in  the  analysis  of  VC’s  is  to  simplify 
and  eliminate  the  trivial  parts  so  that  one  can  see  the  real  verification  proolems.  It  is 
inappropriate  to  process  these  unsimplified  VC’s  with  the  theorem  prover  because  there  are  faster, 
less  general  techniques  for  carrying  out  logical  and  algebraic  formula  reduction  VC’s  are  first 
processed  by  a simplifier.  Originally,  we  had  planned  the  simplifier  as  a preprocessor  to  the 
theorem  prover,  but  our  current  methodology  r, lakes  repeated  interactive  use  of  the  simplifier 
before  using  the  prover  (See  Figure  I) 
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Let  us  first  state  very  briefly  what  the  simplifier  does  (Full  details  In  [Suzuki]).  The  user  ma> 
submit  three  kinds  of  documentation  statements  which  will  be  used  as  reduction  rules  by  the 
simplifiei  Here  are  examples  of  each: 

AXIOM  CA  R(CONS(»X.i»Y))**X; 

This  means  that  any  term  in  a VC.  (hat  "matches"  the  left  side  (i.e.  is  identical  to  the  left  side 
when  X and  Y are  replaced  jy  appropnate  strings)  will  be  replaced  in  the  VC  by  the  string  for 
X It  is  a left  to  right  reduction  rule  A variable  preceded  by  "a"  is  called  a pattern  variable 

AXIOM  IF  ISTERMLIST(L)ai(L-ZERO)  THEN  ISTER M(HD(®L))«TRUE 


This  is  a conditional  axiom  Suppose  a VC  has  the  form  A-*B  Any  expression  in  B that 
matches  ISTERM(HD(i»L))  may  be  reduced  by  this  rule  to  TRUE  If  ISTERMLIST(L)  and 
■’(L-ZERO)  (where  L is  the  substitution  string  for  t?L  in  the  successful  match)  occur  In  A. 

GOAL  RC.ONS(i*X  l,»Y l)-RCON$(*X2.«Y2)  SUB  (X  I - X2)a(Y  I - Y2) 


This  is  a goal  statement.  It  is  treated  as  a reduction  rule  that  says  "an  expression  that  matches  the 
GOAL  may  be  replaced  by  TRUE  if  the  corresponding  instance  of  the  SUBgoal  can  be  reduced 
to  TRUE 

Figure  2 shows  a program  with  documentation  that  will  be  used  as  simplification  rules. 

Goal  statements  can  be  formulated  as  conditional  axioms  and  vice  versa.  The  difference  is  that 
axioms  are  "sticky”  (any  reduction  by  an  axiom  is  never  reversed)  whereas  goals  are  not  (goals 
have  no  effect  on  a VC  unless  the  reduction  can  be  pushed  all  the  way  to  TRUE).  Ideally,  the 
axioms  should  consist  of  those  reduction  rules  having  the  property  that  no  reduction  to  TRUE 
depends  on  their  order  of  application. 

The  simplifier  contains  a sequence  of  simplifying  "boxes"  An  incoming  VC  is  simplified  in 
sequence  by  (I)  a logical  proposition  simplifier,  (2)  processing  of  arithmetical  expressions  by  choice 
of  standard  forms  and  by  evaluation,  (3)  reduction  by  axioms,  and  (d)  reduction  by  goals 

This  is  a good  place  to  discuss  the  role  of  the  simplifier  in  our  verification  methodology 
Essentially,  we  are  using  the  simplifier  as  a fast  theorem  prover.  Our  philosophy  is  that  the  user 
should  be  able  to  submit  a problem  and  receive  back  the  reduced  VC’s  within  a few  seconds.  If 
the  kinds  of  redurtinn  mles  are  easily  understood,  he  will  probably  be  able  to  see  further  useful 
rules  by  analyzing  the  VC's  He  can  then  resubmit  the  problem  with  additional  rules.  Eventually 
some  of  this  analysis  will  he  automated  (See  Section  3)  and  likely  rules  suggested  to  the  user. 
There  is  no  attempt  to  male  the  set  of  rules  logically  independant  at  first,  the  idea  being  to 
develop  a first  basis  quickly.  It  does  make  sense  to  choose  simple  rules(bclievability),  and  some 
kinds  of  rules  (eg  commutativity)  have  to  be  excluded  because  of  the  way  the  simplifer  works.  If 
all  VC’s  reduce  to  TRUE,  the  set  of  reduction  rules  is  an  adequate  verification  basis. 

The  kinds  of  reduction  rules  have  to  be  simple  also  for  speed  as  well  as  understandability. 
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However,  experience  suggests  that  we  do  need  something  beyond  algebraic  manipulation  The 
goal  statements  form  a simple  theorem  prover.  On  the  other  hand,  some  complex  propositional 
transformations  are  time  consuming  and  often  unneeded,  and  best  left  to  the  theorem  prover. 
Thus  the  boarderline  between  Simplification  and  Theorem-proving,  at  the  moment,  Is  somewhat 
pragmatic 


2.3  AN  EXAMPLE  Figure  2 shows  the  procedure  SIFTUP  used  in  the  algorithm  TREESORT3 
[Floyd]  for  sorting  linear  arrays  of  integers.  The  problem  is  to  verify  that  the  output  of  SIFTUP 
is  always  a permutation  of  its  input.  The  program  contains  an  internal  ASSERTION  as  well  as 
the  entry  and  exit  conditions  for  this  problem. 

There  are  three  reduction  rules  stated  in  terms  of  the  relation  PERMUTATION  (A,B)  meaning 
"array  A Is  a permuation  of  array  B",  and  the  functioi,  ASET(A.i.j)  which  applies  A[l]«-j  to  A. 
We  may  have  no  specific  axiomatic  theory  of  permutations  in  mind  Nevertheless,  the  first  two 
AXIOMS  are  clearly  trivial.  Most  people  will  "believe"  the  third  one  after  a moments  thought. 

The  unsimplified  VC's  put  out  by  VCG  are  in  Figure  3.  So  also  are  the  simplified  ones,  from 
which  we  conclude  that  the  three  rules  are  an  adequate  basis  for  verifying  the  permutation 
property.  The  reader.mav  wonder  how  we  thought  of  the  third  rule.  What  we  did  was  to  run  the 
problem  first  without  it  and  compare  the  premiss  and  conclusion  of  VC«3  or  «4. 


AXIOM  PERMUTATION(Gl,ra|)«TRUE; 

AXIOM  ASET((Sll  ,«l2,ral|[f}l2]MI ; 

AXIOM  PERMUTATION(ASET(ASET«sl  I ,sl2,Ol  I [•I3)),0I3,BI4),BI5)« 
PERMUTATION(ASET(IJ  ,12,14), 15); 

PROCEDURE  SIFTUP(IO,N:INTEGER); 

ENTRY  M*MO; 

EXIT  PERMUTATION(M.MO); 

VAR  COPY:REAL;  J,  hINTEGER; 

BEGIN 

I ♦-  10;  COPY  ♦-  M[l]; 

10:  J - 2 * I; 

ASSERT  PERMUTATION(ASET(M,l,COPY),MO); 

IF  J < N THEN 
BEGIN  IF  J < N THEN 

BEGIN  IF  M[ J*  1 ] > M[J]  THEN  J •-  J»l  ENO; 

IF  M[J)  > COPY  THEN  BEGIN  M[l]  f M[J];  I J;  GO  TO  10  END; 
END; 

M[l]  COPY; 

END; 


Figure  2:  The  procedure  SIFTUP  used  by  TREESORT. 
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• I 

M=MO  -*  PERMUTATION(ASET(M,IO,M[IO]),MO) 

• 2 

(COPY<M[J*l  ])a(M[J]<M[J*I  ])a(J<N)a(J<N)aPERMUTATION(A$ET(M,I,COPY),MO) 
a -♦PERMUTATION(ASET(ASET(M,l,M[JM])fJ*l,COPY),MO) 

(C0PY<M[J])a-(M[J]<M[J*1  ])a(J<N)a(J<N)aPERMUTATION(ASET(M,I,CCPY)  MO) 
-»  PERMUTATION(ASET(ASET(M,IIM[J]),J,COPY),MO) 

• A 


(COPY<M[J])a-(J<N)a(J<N)aPERMUTATION(ASET(M,I,COPY  ),MO) 

-*  PERMUTATION(ASET(ASET(M,I,M[J]),J,COPY).MO) 

• 5 

->(COPY<M[J*l  ])a(M[J]<M[J«  I ])A(J<N)A(J<N)Ar  ERMUTATION(ASET(M,l,COPY)  MO) 
“»  PERMUTATION(ASET(M,l,COPY)  MO)  ’ 

• 6 

-(COPY<M[J])a-(M[  J]<M[  J*  I ])a(J<N)a(J<N)aI'ERMUTATION(ASET(M,!,COPY)  MO) 
-*PERMUTATION(ASET(M,I,COPY),MO) 


■<(COPY<M[J])a-<(J<N)a(J<N)aPERMUTATIONiASET()  .,1, COPY). MO) 
-»  PERMUTATION(ASET(M,l,COP  '),MO) 

• 8 


'(J<N)aPERMUTATIOi\'(ASFT(u  .i.CGf  ,'),M0)  -♦  PERMUTATION(ASET(M,l,COPY),MO) 


THE  SIMPLIFIED  VERIFICATION  CONDITIONS  ARE: 

• I TRUE 

• 2 TRUE 

• 3 TRUE 

• A TRUE 

• 5 TRUE 

• 6 TRUE 

• 7 TRUE 

• 8 TRUE 

TIME:  7 ;PU  SECS,  31  <EAL  SECS 

Figure  3:  VERIFICATION  CONDITIONS  FOR  SIFTUP 
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2.4  HINTS  ON  ANALYSING  VC'S.  Each  VC  corresponds  to  a path  through  the  program 
between  two  assertions  (possibly  the  same  assertion)  A simple  VC  has  the  form  P-*Qc*  where 
Q,  is  the  end  assertion.  P is  a logical  combination  of  the  beginning  assertion  and  boolean  control 
tests,  and  c<  Is  a substitution  of  terns  for  program  variables  If  the  path  contains  function  or 
procedure  calls,  the  form  of  the  VC  is  more  complex.  The  VC  expresses  a logical  condition  on 
the  action  of  the  program  along  the  path  It  also  contains  implicitly  a description  of  the  path  and 
what  the  action  is 

(a)  The  path  of  a VC  is  determined  by  the  values  of  the  boolean  control  tests  occurlng  in  P. 

(b)  The  computational  changes  can  be  determined  from  terms  substituted  for  program 
variables  by 

EXAMPLE  VC4  (figure  3)  corresponds  to  the  path  from  the  ASSERTION  satisfying  JCN, 
-<(J<N),and  M[J]>COPY  back  to  the  ASSERTION.  The  action  of  o c (determined  from  the  Q 
part  of  VC4)  is  M*-ASET(M,I,M[J])  (i.e.  and  l*-J  The  assignment  cannot  be 

detected  unless  ASSERTION  contains  J. 

Our  methodology  depends  on  extracting  information  from  VC's.  When  a VC  does  not  reduce  to 
TRUE,  the  programmer  may  try  to  decide  if  it  is  true  using  his  knowledge  of  the  program  (i.e.  the 
path  and  action)  If  it  is  true,  he  can  either  expand  P (I.e.  the  beginning  assertion)  or  give 
•idditional  documentation  in  ordei  to  prove  the  VC.  Additional  documentation  can  be  given  by 
placing  i.ew  assumptions  in  the  basis  If  the  VC  appears  to  be  false,  he  has  either  to  weaken  the 
specifications  \Changirg  P or  Q)  or  to  change  the  program 

Commonly  occuting  situations  include  the  following 

(i.V  Paths  of  VC's  conespond  with  cases  the  program  is  supposed  to  recognize.  Any  kind  of 
mismatch  of  cases  and  paths  indicates  a change  should  be  made  in  the  program. 

(II) .  The  action  of  a VC  does  not  express  what  the  program  was  intended  to  do  in  the  case 
corresponding  to  the  VC  path.  A change  in  the  program  is  necessary  (see  3.1  (b),(c)). 

(III) .Part  of  Q,  Is  logically  |r  dependant  of  P.  Then  usually  P should  be  expanded  (see  3.1(a) 
and  (d)) 

(iv).  The  VC  appears  true  but  not  provable  from  the  the  current  Basis.  Analysis  of  the 
components  of  and  related  parts  of  P can  often  yield  conditions  on  functions  and 
procedures  which  were  overlooked  or  were  omitted  because  their  relevence  was  questioned. 
These  may  then  be  added  to  the  Basts  (see  3.3  a.b.c). 

How  much  of  this  analysis  and  corrective  action  can  be  automated  ? Most  of  the  current  attempts 
to  automate  the  construction  of  assertions  (especially  in  case  (lit))  assume  that  the  program  Is 
t Iready  correct  If  we  do  not  assume  correctness,  it  seems  that  the  choice  of  action  ( whether  to 
change  the  documentation  or  the  program)  depends  entirely  on  the  programmer's  Intentions  and 
cannot  be  automated.  However,  much  can  be  done  to  automate  the  extraction  of  Information 
from  VC’s  The  sys' m helps  by  displaying  the  (updated)  effe-:*  of  any  changes  and  allowing 
experimentation 
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3.  CASE  STUDY:  METHODOLOGY  IN  ACTION 

v v"  'faln  Unlf,ca"°n  lnf°,ma"v  A P"V=™  ac«p,s  as  Input  two  lists  of 

o(  \ ,oY„::d'T:UC,S  as  “'T  a sutmi'u,i0'’  (of  "rms  ,cr  tint  makes  each  member 

-|MPO«m  r-  r corresponding  member  of  Y ,f  posstble.  or  els.-  outputs  the  answer 

shou^pu,  ou,E,heFu°: *«***JU  -He  program' 
It  Is  possible  to  write  such  first-order  unification  programs  In  many  different  ways  A DODular 


We  asked  an  experienced  programmer  to  write  a unification  program  In  real  time  (whil.  us. 
ooked  on).  We  note  the  following  He  stated  h,s  intention  to^the  Input  da  r e, u s a 
temporary  storage,  but  no  structures  were  declared  He  attempted  to  code  "top  down”  naming 
subfunctions  without  coding  them,  but  merely  stating  what  they  were  supposed  mdo  (but’ he  often 
changed  his  mind).  As  the  program  developed,  he  had  difficulty  documenting  th.  innn  a 
introduced  virtual  program  to  do  this  (without  telling  us).  He  gave  up  on  theg  Idea  or  SuJelv 
Iterative  code  and  ended  up  putting  a recursive  call  Inside  a WHILE  loop.  ^ ^ 

It  is  this  program  that  we  start  with  as  VERSION  I.  We  make  no  claim  that  it  is  how  , 
unification  program  should  be  coded.  We  choose  it  because  it  Is  the  result  of  a «al  life  slmahon 
and  Is  a problem  of  sufficient  richness  to  be  a good  test  of  our  ideas  on  methodology. 

m,mlKrlU0vb'  T""*  “ ,ha;  ,h'  pr°Sr>n’  !,°PS'  f"h"  « outputs  a unifies  Z of  the  input 
. ' ! * "d  Y or  ' °“,PutJ  * fallur'  0,h'f  standard  find  complementary)  properties  that  will 

,7"";;""'  ,ha'  Z a e™’'  “"*•  >"d  * - Slto.  » oVpu.Vn  X a”d  Y 

:„h;  “P  P"*™ ls  d'v'loP'd  Mpc  wrata!  I (a  fin,  skech).  a debugged  venlon  2 

■,:z:x^x;r,’Ss.z  z‘r,rz  ci~r- 

ssssr.ssr  — ~ -—'-mssu  vs 
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The  subf unctions 
TSUBST(\,Z)  - 
SUBST(X.Z) 
ZERO 

COMP(Z.X.Y)  - 

OCCUR(X.Y)  • 
RCONS(U.X)  ■ 
TERMS(X) 
FNLT(X) 

HD(X).  TL(X)  - 


usfd  In  the  program  have  the  following  Intended  meanings 
the  term  resulting  ftom  applying  substitution  Z to  term  X, 
the  teimlist  resulting  from  applying  substitution  Z to  termlist  X, 
the  empty  list. 

the  substitution  resulting  from  composing  substitution  Z with  the  single 

substitution  that  replaces  variable  X by  term  Y, 

a Boolean  test.TRUE  whenever  term  X is  a subterm  of  term  Y 

termlist  obtained  by  adding  term  X to  the  end  of  termlist  U, 

the  termlist  consist  of  the  arguments  of  term  X (not  a simple  variable), 

the  function  letter  of  complex  term  X, 

the  head  and  tail  of  list  X 


3.1  VERSION  I:  DEBUGGING  AND  EXTENDING  DOCUMENTATION.  Version  I is  the  top 
levpl  of  the  program  that  was  initially  submitted  for  verification  It  was  written  almo‘1  on-line  an^ 
therefore  contains  bugs  and  even  misconceptions  of  the  structure  of  algorithm  and  data.  Roughlv 
speaking  i is  a sketch  of  a progiam  with  the  question  "can  this  be  made  to  work?"  It  does  not 
include  any  specifications  of  the  data  types  (in  form  of  axioms,  deffuns  etc  ).  The  invariant  of  the 
main  loop  consists  just  of  the  mam  idea:  the  initial  parts  of  the  termlists  X and  Y are  unified  by 
the  constructed  substitution  Z.  To  express  this  the  programmer  used  two  "ghost  variables"  [Clint] 
U and  V,  which  hold  the  parts  alieady  dealt  with,  and  "virtual  program",  i.e.,  statments  that  are 
not  necessary  for  the  actual  computation.  Failure  of  the  algorithm  is  expressed  by  the  pseudo- 
procedure LOSE 

Note  that  the  progiam  contains  several  gs: 

- the  cases  structure  is  Incoiiect, 

- after  the  recursive  call  cf  UNIFY  the  result  is  not  tested  for  success  or  failure  and  the  returned 
substitution  is  not  assigned  to  Z, 

- at  the  end  of  the  procedure  it  is  not  guaranteed  that  both  XI  and  Yl  are  ZERO. 
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PROCEDURE  UNIFY (X,Y:TERMLtST ;2 1 :SUB;  VAR  7:$UB); 
ENTRY  ISTERMUST(X)aI3TERMLIST(Y); 

EXIT  (S UB ST (X ,Z)-SUBST (Y,2))  v L0SE(X,Y); 

VAR  U,V,XI,YI:TERMLIST;  VAR  X2,Y2:TERM;  VAR  22:$UB; 
BEGIN 


7.  Initialization  of  variables  7. 

U:«2ER0;  V.-2ER0;  2:-2l;  X I :-X;  Y1  :-Y; 


INVARIANT  (SUBST(U,2)*SUBST(V,2))  " LOS £(X,Y) 

WHILE  (XI/2ER0)  a (YI/2ER0)  DO 
BEGIN 

X2:«  SUBST(HD(X  1 ),2); 

Y2:«  SUBST(HD(YI  ),2); 

IF  ISVAR(X2)  THEN  BEGIN  IF  ISVAR(Y2)  THEN  2:*COMP(2,X2,Y2); 

IF  OCCUR(X2,Y2)  THEN  LOSE(X.Y) 

ELSE  2:*COMP(2,X2,Y2) 

END 

ELSE  BEGIN  IF  ISVAR(Y2) 

THEN  BEGIN  IF  OCCUR(Y2,X2)  THEN  L0SE(X,Y; 

ELSE  2:*COMP(2,Y2,X2) 

END 

ELSE  BEGIN  IF  FNLT(X2)*FNLT(Y2) 

THEN  UNIFY(TERMS  (X2), TERMS  (Y2),  2,22) 
ELSE  LOSE(X.Y) 

END 

END; 

U :*RCONS(U,HD(X  I ));  V :*RCONS(V,HD(YI )); 

X I :*TL(XI );  Y1  :«TL(Y1 ); 

END;  1 End  ot  WHILE  body  7. 

END;  7.  Procadura  body  7 


Figure  4:  Version  I 
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LOSE  NOT  FOUND 


• J 

(ISTERMLIST(Y)  ft  ISTERMLIST(X)  ft  LOSE(X.V)  v SUBST(U*1  ,Z»1  )*SUBST(V«  1 (Z*  1 ) ft 
~YI«l'ZERO  a -XUl'ZERO 
-♦  LOSE(X,Y)  v 3UBST(Y,Z«I  )-SUBST (X,Z*1 )) 

• 3 

(LOSE(X.Y)  v SUBST(U,Z)»SUBST(V,Z)  ft  -Yl-ZERO  ft  -Xl-ZERO  ft 
-ISVAR(SUBST(HD(X1  ),Z))  ft 

-ISVAR(SUBST(HD(Y1  ),Z))  ft  FNLT(SUBST(HD(Y1  ),Z)>-  FNLT(SUBST(HD(X1  )tZ)) 

-*  ISTERMIJST(TERMS($UBST(HD(Y1),Z)))  ft 
(LOSE(TERMS(SUBST(HD(Xl  ),Z)),TERM$($UBST(H'j(Y1  ),Z)))  v 
SUBST(TERMS(SUBST(HD(YI  ),Z)),Z2«I  )«SUBST,  rERMS(SUBST(HD(XI  ),Z)),Z2*1 ) 

-*  LOSE(X.Y)  v SUBST(RCONSCU,HD(X  1 )).Z)«SUf IS T(RCONS(V,HC  Y1)),Z))  ft 
ISTtRMUST(TERMS(SUBST(HD(Xl 

• 9 

(LOSE(X,v)  v SUBST(U,Z)*SUBST(V,Z)  ft  -Y1.ZER0  ft  *X1«ZER0  ft 
ISVAR'SUBSTtHD(Xl),Z))ft 

ISVAR(SUBST(HD(Y1),Z))  ft  0CCUR(SUBST(HD(Xi),Z),SUBST(HD(YI),2)) 

-*  PRE.LOSE(X.Y)  ft  (RE3_L0SE(X,Y) 

-*  LOSE(X.Y)  v 

SUBST (RCONS(U,HD(Xl  )),C0MP(Z,$UB5T(HD'X1  ),Z),SUBST(HD(Y1  ),Z))) 
■SUBST(RCONS(V,HD(Yl  )),COMP(Z,SUBST(HO(XI  ),Z),SUBST(HD(Y1  ),Z))))) 


Figure  5:  Some  VC’*  for  version  I in  simplified  form 
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Corresponding  to  the  lack  of  any  detailed  information,  the  system  Is  not  able  to 
'han  the  most  trivia!  parts  of  the  generated  VC's. 


simplify  more 


Discussion  of  the  problems  involved  in  version  I: 


a)  Failure  Handling:  Trying  to  define  pre-  and  post-condit.ons  for  the  missing  procedure  LOSE 
as  required  by  the  system,  the  programmer  realizes  that  indication  of  failure  is  a change  of  the 
state  rather  than  an  act  on  to  be  invoked  (a  direct  way  to  put  across  an  error  message  ee  m form 
o a jump  to  the  top  >vel  is  not  available  ,n  Pascal)  Thus,  he  should  use  a boolean  varlab" 

FLAC  whose  vniK  id.cate  success  or  failure  Accordingly,  the  r ocedure  UNIFY  gets  one 

more  vai , able  parameter,  sue!  that  it  returns  the  value  of  FLAC  together  with  a new  value  of  * 

10  L0SE  15  t0  rePlacpd  by  FLAC  «0,  and  the  initial  value  of  FLAG  will  b“  I The 
EXIT  assertion  must  be  changed  to  specify  the  use  of  FLAG 

EXIT  ( $UBST(X,Z)'SUBST(Y,Z)  a FLAC- 1)  v FLAG-0 
An  equal  ;nange  oust  be  made  ,n  the  INVARIANT  (If  the  INVARIANT  is  not  changed  the 

s7e  sI!tlo?2  40H)!'nge  W‘"  * **"  rU"S  ln  thc  path  ,MdlnS  from  thp  looP  K»  the  EX  IT. 7 

b)  Missing  Code:  The  necessity  to  update  the  value  of  Z after  the  recursive  call  to  UNIFY  r,n  h* 

detected  by  analysing  VC?  The  relevant  parts  are  C*n  be 

-ISVAR(SUBST(HD(X  i),Z))  Sc  -ISVA R(SUBST(HD(Yl)Z))  & 

FNLT<SUBST(HD(YI),Z))-FNLT(SUBST(HD(XI),Z))frSUBST(U.Z)-SL  BST(V  7) 

- aUBST(TERMS<SUB3T(HD(YI),Z)),Z2«l).SUBST(TERMS(SUBST(HD(XI)Z))Z2.n 

- SUBST(RCONS(U.HD(XI)),Z)-SUBST(RCONS(V,HD(YI)),Z)  ^ ” * 0 

VC.3  as  It  stands  is  not  provable  (there  are  obvious  counterexamples).  The  first  two  lines 

' r r*  n*1  11  corre’Ponds  t0  thf  Path  containing  the  procedure  call  UNIFY(..,Z2).  The  purpose 

n v |S  IT  'Xr  Z t0  3 substltut,on  22  tbat  unifies  the  pair  HD(X  I)  and  HD(YI)  asPwell  as 
U and  V Indeed  the  occurences  of  Z in  the  last  line  of  VC*3  should  be  Z2.I  The  final  value 

of  Z at  the  end  of  the  path  should  be  the  value  of  Z2  returned  by  UNIFY  If  the  attempted 
unification  succeeds  Thus  the  action  on  the  path  is  not  what  was  Intended,  and  the  code  mutt  be 
changed-  Section  2.4(n;  The  coirect  action  can  be  achieved  by  adding 


IF  FLAC- 1 THEN  Z -Z2; 


Immediately  after  the  call 


«£L\:TK  VC' 9 " °f  ,0rm  rM<im  Th'  I-*"™*  notices  the 


ISVAR(A)/\ISVAR(B)aOCCUR(A,B) 


in  part  P.  This  means  that  VC.9  expresses  a condition  on  the  action  of  the  program  alone  the 
path  corresponding  to  this  combination  of  cases.  This  action  can  be  deduced  from  O and  R the 
procedure  LOSE  is  called,  and  the  substitution  Z Is  updated  to  COMP(?c,D)  This 
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combination  of  actions  is  dearly  wrong,  indeed,  the  programmer’s  intention  in  this  case  is  that  the 
program  should  do  nothing  to  Z and  continue-another  example  of  Section  24(d).  This  error  is 
fixed  by  adding  an  e .tra  IF  statement  for  the  case  1SVAR(X2)aI$VAR(Y2)a(X2>iY2)  (see  figure 
6) 

d)  Expansion  of  the  INVARIANT:  To  state  the  invariant  of  the  loop,  the  programmer 
introduced  the  variables  U and  V which  are  ir/ended  to  hold  the  values  for  the  initial  parts  of 
the  termlists  X and  Y From  looking  at  VC«I  he  can  see  that 

(1)  SUBST(U,Z)-SUBST(V,Z) 
has  to  Imply 

(2)  SUBST(X,Z)-SU3ST(Y,Z) 

when  control  leaves  the  loop,  ie  when  X 1-ZERO  and  YI-ZERO,  and  the  algorithm  Is  successful. 
This  is  impossible  unless  some  relationship  between  U,V  and  X.Y  respectively  Is  given  - an 
example  of  Section  2 4(m)  Now,  th«.  intended  relationship  is 

(3)  A PPEND(U,X  1)«X  a APPEND(V,Yi)-Y 

where  APPEND  is  the  standard  LISP  function.  The  question  is,  where  should  th>s  be  added  to 
the  documentation?  Further  analysis  of  VC«I  shows  that  the  only  possible  place  is  the  Invariant 
of  the  loop  (the  other  parts  of  the  VC  derive  from  entry  and  exit  condition  and  the  loop  control 
test)  The  obvious  properties  3f  APPEND 

(4)  APPEND(ZERO,L)«L  APPEND(L.ZERO)-L 

will  be  assumed  as  axioms,  guaranteeing  that  (3)  v ill  be  true  when  entering  and  leaving  the  loop. 
Then.  (I)  will  imply  (2).  provided  borli  XI  and  Y I equal  ZERO  at  the  end.  On  the  next  run  with 
the  two  axioms  on  APPEND  added,  the  omission  of  a corresponding  test  after  leaving  the  loop 
will  be  visible  in  the  VC,  so  a statement 

IF  (XirZERO)  v (Y l^ZERO)  THEN  FLAC.-O; 
is  added  at  the  end  of  the  procedtne 

REMARK  The  programmer  could  as  well  try  to  figure  out  what  other  properties  of  APPEND 
are  required  to  prove  invariance  of  the  invariant  around  the  loop,  but  he  leaves  that  to  the 
system  as  he  hopes  to  find  what  is  needed  from  the  VC’s  of  a subsequent  run  (refer  to  Section  3 3 
b)  Note  that  the  function  APPEND  is  used  only  in  the  documentation. 

e)  Use  of  Ghost  Variables  and  Virtual  Program:  As  a data  flow  analysis  would  show,  the 
variables  U and  V are  not  necessary  to  compute  the  final  result.  They  are  needed  only  to  express 
the  invariant  of  the  main  loop  Therefore  they  are  called  "ghost  variables"  [Clint].  Obviously, 
assignments  to  ghost  variables  need  not  be  executed  at  run  time  nor  translated  by  a compiler. 
Thus  these  statements  are  considered  "virtual";  their  purpose  is  to  ensure  the  correct  current 
values  of  the  ghost  variables  as  the  computation  proceeds. 
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The  technique  of  using  ghost  variables  and  pieces  of  virtual  program  for  documentation  purposes 
is  very  useful  and  quite  common  Although  they  often  could  be  eliminated  as  part  of  the  program 
text  - especially  in  the  context  of  arithmetical  problems  where  most  operat  ons  are  invertible  - they 
represent  a powerful  tool  Whethr  a programmer  chooses  virtual  program  or  not  depends  on  his 
preferences  and  the  problem  domain  In  our  example,  U and  V could  be  replaced  In  the 
invariant  by  expiessions  like  EXCLUDE(X  l,X)  meaning  the  remaining  Initial  list  after  chopping 
off  XI  from  the  right  end  cf  X In  this  way,  EXCLUDE  becomes  sort  of  an  inverse  function  of 
APPEND  However,  we  preler  .he  virtual  program  approach  since  it  expresses  clearer  the 
building  up  of  the  values  of  U and  V simultaneously  with  the  other  compulsion,  beside  that,  the 
axioms  and  goals  involving  the  equalities  SUE‘;T(U,...)-SUBST(V>...)  are  complicated  ever 
without  the  difficulties  added  by  the  use  of  EXCLUDE,  as  will  be  seen  later. 


3.2  DATA  TYPES  AND  TYPE  CHECKING  For  program  verification,  data  type  definitions 
represent  sets  of  axioms  defining  the  semantics  of  the  types.  They  are  primitive  statements  in  the 
verification  basis  This  i*  usually  called  the  "abstract"  definition  of  a data  type.  A handy  formalism 
is  needed  that  permits  the  programmer  to  define  his  types  without  having  to  write  down  all  the 
axioms  explicitly  The  unification  program  here  uses  recursive  types.  We  adopt  the  following 
formalism  for  defining  recursive  data  types.  It  is  closely  related  to  suggestions  of  [McCarthy  1963] 
and  [Hoare  1973],  and  Is  an  extension  of  and  a departure  from  what  is  possible  In  the  present 
version  of  Pascal. 


A type  definition  is  made  by  listing  alternatives.  An  alternative  is  either  a simple  type  (e.g.,  one 
that  is  a type  predefined  in  the  language,  or  a constant)  or  a composed  type.  In  a more  formal 
BNF-like  notation 


<type  definition* 
<type> 

ccomposed  type* 

<simple  type* 
<con  straint* 


*■  <type  name*  <type>  { | <type>  }<> 

*-  csimple  type*  | ccomposed  type* 

*-  cconstructor*  ’(  cselector  l>  <type_l>, . . ,<selector  n*  <type  n>  ') 
{’IF  cconstraint*} 

*-  <constant>  | ctype  name* 

*-  cboolean  expression  of  selector  names* 


with  the  restriction  that  the  names  of  all  constructors  in  a type  definition  and  all  selectors  in  one 
composed  type  have  to  be  distinct.  The  formal  type  definition  syntax  permits  simple  kinds  of 
constrains  tc  be  placed  on  a constrtu’or.  The  meining  of  the  constraint  is  that  in  order  to 
constuct  an  element  of  the  type,  the  constuctor  must  be  applied  to  arguments  thi't  satisfy  the 
constraining  condition  (an  example  is  the  type  SINGLESUBstitutiou  below) 

In  this  notation,  the  data  types  to  be  used  In  our  program  may  be  defined  by  the  following  (only 
the  upper-case  letter  part  of  the  names  is  used  in  the  programs): 

TFPM  VAR  | MKTERM(FNLT.CONST,  TERMS  TERMLIST) 

TERMLIST  .-  ZERO  | CONS(HD:TERM,  TLTERMLIST) 

SINGLESUBstitution  - PAIR(VAR  VAR,TERM:T£RM)  IF  - OCCUR(VAR.TERM) 
SUBstltution  ZERO  | MKSUB(REST:SUB,  LAST.SINGLESUB) 


1 % 
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VARiables  and  CONST ants  are  assumed  as  primitive  types.  TERMLIST  is  just  a linear  lisi  of 
TERMs.  The  constraint  on  SINGLESUB  means  "Z-FA1R(V,T)  is  a SINGLESUBstitution  only  if 
V does  not  occur  in  T " 

Notation  IS<typename>  denotes  the  type  predicate  (i  e.  characteristic  function)  for  <typenarne> 

The  type  definition  determines  the  logic;il  type  of  all  the  functions  occuring  in  it  (constructors  and 
selectoi s)  For  example,  HD  maps  TERMLIST  into  TERM,  and  MKTERM  is  a func  ion  from 
CONST  TERMLIST  into  TERM  ( direct  product)  It  is  assumed  that  a selector  function  Is 
defined  only  for  objects  belonging  to  the  corresponding  constructed  subtype 

At  present  the  verifier  does  not  yet  accept  type  definitions  but  needs  to  be  given  the  type  axioms. 
The  definition  of,  eg,  SUBstitution  denotes  a set  of  axioms  including  standard  relationships 
between  constructc::  tnd  selectors 

ISSUB(ZERO) 

IF  ISSUB(A)/\ISSINGLESUb(B)  THEN  ISSUB(MKSUB(A,B)) 

REST(MKSUB(/  ,B))-A 
LAST(MKSUB(A,B))-B 

,xnd  the  induction  rule 


F(ZERO)  F(A)  | F(MKSUB(A,B)) 


ISSUB(S)  |-  F(S) 

for  my  formula  F 

The  functions  defining  a type  (constructors  and  selectors)  are  submitted  to  the  system  as 
DEFFUN's  If  there  are  constraints  on  a type  (as  for  SINGLESUB),  type  checking  also  involves  a 
check  if  those  conditions  hold  whenever  a new  object  of  the  type  is  constructed;  thus,  the 
constiamts  become  part  of  the  ENTRY  assertion  of  the  DEFFUN  for  the  respective  constructors. 
When  the  program  is  augmented  by  DEFFUN's  for  all  subfuncticn:  the  system  will  generate 
complete  argument  type  checks  as  part  of  the  VC’s.  However,  for  reduction  of  the  vC’s  the 
assertions  have  to  include  a type  predicate  for  each  variable  that  Is  passed  as  a parameter  to  a 
function  or  procedure  In  this  way,  the  verifier  will  do  type  checking  automatically. 

While  formulating  the  type  declarations  for  the  sub.unctions  it  was  noticed  that  in  the  use  of 
SUBST  in  the  iNV  .RIANT  the  first  argument  is  a termlist  whe^as  in  its  function  calls  in  the 
assignment  statements  the  first  argument  is  a term.  In  order  to  avoid  .his  type  conflict  a separate 
function  TSUBST  is  introduced  for  application  to  firms. 
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3.3  VERSION  2:  CONSTRUCTING  /.  BASIS.  Version  0 of  the  procedure  UNIFY  (see  figure 
6 ( i the  next  page)  is  a conect  piogra  ii  in  the  «ns?  that  the  code  does  satisfy  the  ENTRY/EXIT 
assn  firms  The  assntioiis,  (including  the  invariant)  have  been  expanded  to  a point  where  they 
ought  to  he  sul'kiently  detailed  This  version  contains  those  axioms  and  goals  that  are  naturally 
anticipated  by  'he  piogianimer  Among  those  arc  axioms  that  express  intended  properties  of  the 
data  types  and  siibfunctions  In  older  to  speed  up  the  simphfer,  only  ’hose  data  type  axioms  that 
were  realty  needed  have  been  added  The  DEFFUN’s  for  the  basic  data  type  functions  have  also 
been  included,  they  consist  of  just  the  obvious  input  and  output  specifications  (estentla lly  type 
information) 

What  still  'emams  to  lie  done  is  to  establish  an  adequate  basis  for  verifying  the  top  level.  I.e., 
completion  of  the  documentation  Be'ow  we  demonstrate  techniques  for  constructing  the  basis  by 
extracting  from  the  reduced  VC.’s  additional  specifications  (or  "lemmas")  on  the  subful, ctions 
which  are  behevabl?  and  which  permit  the  system  to  completely  reduce  the  VC’s  to  TRUE. 


GOALFILE 

7.  Axioms  datming  the  data  types  and  basic  tunctions  7. 

AXIOM  ISTERMLIST(ZERO)  « TRUE; 

AXIOM  ISSUB(ZERO)"TRU£; 

7.  Axioms  describing  properties  ot  subtunctions  7. 

AXIOM  ApFFND(ZERO,raS)«S; 

AXIOM  APPEND(«bS,ZER0)«S; 

AXIOM  SUBSTdsX.ZEROHX; 

AXIOM  SUBST(ZERO,oS)*»ZERO;.; 

PASCAL 

DEFFUN  HD(L:TERMUST):TErM;  ENTRY  ISTERMIIST<1)a*(1*ZER0);  EXIT  ISTERM(HD); 

DEFFUN  TL(l:TERMLI$T):TERMLIST;  ENTRY  ISTERMLISTa)A'(l.ZERO);  EXIT  ISTERMLIST(TL); 

DEFFUN  RCONS(l:TERMUST;  X:TERM):TERMll$T; 

ENTRY  I$TERMLI$T(L)aISTERM(X);  EXIT  ISTERMLIST(RCONS); 

DEFFUN  TERMS(X:TERM):TERMLIST;  ENTRY  ISTERM(X)a*ISVAR(X)5  EXIT  ISTERMLIST(TERMS); 

DEFFUN  FNLT(X:TERM):CONST;  ENTRY  I$TERM(X)a-I$VAR(X);  EXIT  ISCONST(FNLT); 

DEFFUN  T SUBST (X;TERM;S:SUB):TERM;  ENTRY  ISTERM(X)aISSUB(S);  EXIT  ISTERM(TSUBST); 

DEFFUN  SUBST(X:TERMLIST;  S:SUB):TERMLIST; 

ENTRY  ISTERMLIST(X)aISSUB(S);  EXIT  ISTERMLIST(SUBST); 

DEFFUN  C0MP(S:SU8;  X:VAR;  Y:TERM):SUB; 

ENTRY  ISSUB(S)aISVAR(X)aISTERM(Y)a-OCCUR(X,Y);  EXIT  ISSUB(COMP); 


Figure  6 Version  2 (continued) 
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/*■ 


F WfMrPURE  EINIFY(X,Y:TERMJ$T;  21  :SU0;  VAR  Z:SUB-  VAR  FL*1'  -nm  caN» 

entry  istermlist(X)aistermlist(Y).  issubczi)  ’ “ 0 *eaN); 

EX.T  (ISSUB(Z)a(SUBST'X,Z)sSUBST(Y,Z))a(FLAG=I  ))  v {FLAG  . 0); 

BEGIN ’V’XI'YI:TERML,ST:  VAR  *2-Y2:TERMi  VAR  22:SUB; 

1.  Initialization  of  variables  7 
L!:*ZER0;  \ ->ZER0;  Z:«ZI ; X 1 :-X;  YI:*Y;  FLAG:*! ; 


WHILE  (XI/ZERO)  a (Y1/ZER0)  / (FL AG=  I ) DO 
BEGIN 
a‘2:»  TSUBST(HD(XI),Z); 

Y2:=  TSUBST(H0(YI  ),Z); 

IF  ISVAR(X2)  THEN  BEGIN  IF  ISVAR(Y2) 

THEN  BEGIN  IF  (X2/Y2) 

THEN  Z:*COMP(Z,  X2.Y2  ) 

END 

ELSE  BEGIN  IF  OCCUR  (X2.Y2)  THEN  FLAG-0 

ELSE  Z:rC0Wp(2.  X2.Y2  ) 

END 

END 

ELSE  BEGIN  IF  1SVAR(Y2) 

THEN  BEGIN  IF  OCCUR(Y2,X2)  THEN  FLAG:*0 
ELSE  Z:*COMP(Z,Y2,X2) 

END 

ELSE  BEGIN  IF  FNLT(X2)*FNLT(Y2) 

THEN  beoin  Tra&’sr 

END 

ELSE  FLAG:=0 

END 

END; 

U :=RCONS (U,KD(X  1 ));  v :-RCONS(V,HD(YI  ))• 

X 1 :=TL (X I )•  VI  :«TL(YI ); 

END;  7 End  of  WHILE  body  7. 

IF  (XI /ZERO)  v (Y I /ZERO)  THEN  FLAG.--0 
END;  7 Procedure  body  7 


v (FLAG*0) 


Figure  6:  Version  2 (iiHcrwcdiale  version) 
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VC's  13  5 6 8 are  reduced  to  TRUE 


• 2 

(ISTERMLIST(X)  A ISTERMLIST (Y)  A ISSUBIZ* I JaISTERMLIST (U*  1 )a!STERMLIST(  V»  1 ) 
aSUEST(U«111»I  ) SUGST(V»I,Z»I  )aU«I  Xr  V«KY.'.FLAG«I  = 1 vFLAGaHO  A ISSUB(Zl) 
-*  ISSUB(Z«I  )aSUBST(Y,Z«I  )- SUD ST I )aFLAG« ! = I vFLAG»l  =0) 


■ 4 

(ISTERMLIST (RC0N5(V,MD(Y I )))  A «S TERMLIST(RCONS (U,HD(X  1 )))  A I$TERML!$T(TL(Y1 ))  A 
I$TERMLIST(TL(X1 ))  A ISSUU(Z2»?)  A 

SUBST(TERMS(TSUBST(Mn(YI),Z))1Z2*2)-SUBST'TERMS(TSUBST(HD(Xl),Z)),Z2«2)  A 
ISCONST(FNLT(TSUBST(HD(Y!  ).Z)))  A ISTERMLIST (TERMS(TSUBST(HD(Y  I ),Z)))  A 
ISTERMUST(TERMS(TSUBST'HD(XI  ),Z)))  A 

FNLTJSU8ST(HD(YI  ),Z)KFNIT(TSUBST(HD(XI  ),Z))  A -ISVAR(TSUBST(HD(X  1 ),2))  A 
-1SVAR(TSUBST(HD(YI  ),Z))  A SUBST(U,Z)=SUBST(V,Z)  A 

ISSUBfZ)  A iSTERMLIST(U)  A ISTERMLIST(V)  A ISTERMLIST (XI)  A ISTERMLIST (Y 1 ) A 
-Y 1 *ZERO  A -X 1 =ZERO  A 1STERM(TSUGST(HD(Y  1 T,Z>)  A ISTERM(HD(Y I ))  A 
l$TERM(TSUBST(HD(Xl),Z))  A ISTERM(HD(Xl )) 

-*  APPiNU'V.YI  )--APPEND(RC0N3(V,HD(Yl)),TL(YI ))  A 
APPEilD(U,XI  )=APP£ND(RCONS(U,HD(XI  )),TL(X I ))  A 
$UBST(RCONS(U,HD(XI ) ).Z 2 - 2 )= SUB ST( RCONS ( V,H0(Y  1 )),22»2)> 

• 10 

(-XHZER0  A SUBST(U,Z)=SUBST(V,Z)  A ISTERMUST(YI ) A ISTERMLIST (X 1 ) A 
ISTERMLIST (V)  A ISTERMLIST (U)  A ISTERMLIST (RCONS (U,HD(X  I )))  A 
ISSUB(Z)  A -Y I =Z”PO  A ISTERM(HD(X I ))  A ISTERMLIST (PCONS(V,HD(V I :))  A 
ISTERMLISTC'LJYI ))  A ISTEPMLIST(1L(XI ))  A ISVAR(TSUBST(HD(Y1  ),Z))  A 
TSUBST (HD(Y1  ),Z)=T SUBST (HD(X  1 ),Z)  A ISTERM(TSUBST(HD(YI  ),Z))  A l$TERM(HC(\  I )) 

-*  SUBST (RCONS(U,HD(X  I ) ),Z )= SUO ST (RCONS(V,HD(YI  )),Z)  A 
APPEND(U,X1  )-APPEND(RCONS(U,IID(XI  )),TL(X1 ))  A 
APPEND(V,Y  1 )= APPEND(RCONS(V,HD(V  I )),TL(Y  1 ))) 

• I I 

(SUBST  (U,Z)=$UBST (V,Z)  A ISTERMLIST (Yl ) A ISTERMLIST (X I ) A ISTERMLIST(V)  A ISTERMLIST(U)  & 
ISSUB(Z)  A A -XHZEPO  -YHZEPO  A IS VAR{TSUB ST(HD(Y  1 ),Z » A !STEKM(HD(Y1 })  A 
ISTERM(TSUBST(HD(XI  ),Z))  A 

ISTERM(HD(X I ))  A ISVAR(TSUBST(HO(XI),Z))  A ISTERM(TSUBST(HD(Y  1 ),Z))  A 
-<TSUBST(HD(Y1  ),Z)=TSUOST(HD(X I ),Z) 

-♦  -OCCUR(TSUBST(HD(X  I ),Z),TSUBST(HO(YI  ),Z))  A 

(ISTERMLIST (TL(X  1 ))  A ISSUB(COMP(Z,TSUBST(HD(X I ),Z ),TSUBST(HD(V  1 ),!)))  A 
ISTERMLIST(RCONS(V.HD(Y I )))  A ISTERMLIST (RCONSIU.HDIX I )))  A I3TERMLI$T(TL(Y  1 )) 

-*  APPEND(V,Y1KAPPEND(RCCNS(V,H0(YI)5,T'.(YI))  a 
APPENDOJ.X  I )rAPPEND(PCONS(U,HO(X : )),TL(XI ))  A 

SUBST  (RCONS (U,HD(X  I )),COMP(Z,TSUBST(HD(X  I >,Z ),T SUBST ( HD(Y  1 ) Z))KSUB$T(RC0N3(V,HD(Y1 )), 
COMP  (Z,T  SUB  ST  (HD(X  1 ),Z),TSUBST(HD(Y|  ),Z)))J) 


Figure  7:  Some  VC‘s  for  version  2 in  simplified  form 
The  numbering  coitrspoiids  to  the  order  in  which  the  VC’s  are  generated 
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CONSTRUCTING  A BASIS 


The  analysis  of  the  VC.’s  not  yet  induced  to  TRUE  shows  th.ee  areas  where  the  documentation 
(the  basis)  has  to  be  extended  Each  area  is  independent  from  the  others,  thus  they  can  be  dealt 
with  sepai ately  We  appioach  the  problem  of  proving  a VC  by  first  attempting  to  prove  each 
conjunct  in  the  conclusion  sepai  ately. 

a)  OCCUR  (VC»II)  The  conclusion  of  VC*II  contains  OC.CUR(A.B).  The  path  of  VC«II  is 
detei mined  by  the  contiol  tests  ISVAR(A),  ISVAR(B)  and  A*B  in  its  premise  By  analysing  the 
path,  ->OCC.UR(A,B)  is  found  to  he  an  entry  requirement  of  a call  on  COMP  which  was  intended 
under  these  conditions.  So  this  conjunct  of  VC»II  is  judged  correct,  and  will  be  satisfied  If  the 
user  ag^  < to  adc.  the  following  specification  on  OCCUR  to  the  basis: 

IF  ISVAR(X)aISVAR(Y)a(YXX)THEN  OCCUR(X,Y)-TRUE 

b)  APPEND  (VC's  -4.7.0. 1 0, 1 1):  As  was  mentioned  before  additional  properties  of  APPEND  are 
needed.  It  turns  out  that  exactly  one  fact  crops  up  in  all  the  VC’s: 

A PPEND(RCONS($,HD(7)),TL(T))  . APPEND(S.T) 

The  programmer  might  have  addrd  a lot  of  irrelevant  properties  at  3 1 d)  if  he  had  started  to 
write  down  things  about  APPEND  he  thought  might  be  helpful.  As  seen  here,  it  can  be  more 
efficient  to  write  down  only  very  Simple  axioms  and  delay  anything  further  until  it  is  seen  from 
the  VC.’s  what  is  needed  If  atomic  properties  of  APPEND  and  RCONS  had  been  added  instead, 
the  above  fact  would  have  to  be  deduced  from  them  each  time  it  v-as  required  (here  10  times).  It 
is  much  more  efficient  to  add  the  fact  to  the  basis  at  this  point  and  justify  it  once  during  the 
analysis  of  the  basis  (see  section  3.4).  Moreover,  the  user  can  delay  completely  specifying  PCONS. 

c)  Equalities  involving  SlIBST  and  RCONS  (VC’s  4.7,9,10.11):  As  they  are  the  "heart"  of  the 
problem  the  equalities  involving  SUBST  turn  out  to  be  the  hardert  to  get  reduced.  We  could 
simply  assume  the  properties  of  SUBST  and  RCONS  that  apparently  would  allow  complete 
reduction  to  TRUE  of  all  remaining  VC’s.  But,  beside  the  fac.  that  those  properties  may  be  too 
complex  to  be  believable  even  r.t  the  top  level,  a certain  regularity  can  be  observed  in  the  VC’s, 
due  to  the  structure  of  the  program:  The  equality  in  the  conclusion  is  generally  of  the  form 

(1)  SUBS!  (RCONS(A  !,BI),S)  - SUBST(RCONS(A2,B2),S) 
whereas  the  premise  includes  a corresponding  equality 

(2)  SUBST(A  I, S’)  - SUBST(A2,$’). 

Thus,  it  is  sensible  to  hope  that  lemmas  derived  from  one  problem  will  be  general  enough  to 
reduce  other  problems  as  well. 

Recall  that  applying  a substitution  to  a list  means  epplying  it  to  each  list  element  separately.  So 
the  obvious  way  to  simplify  an  equality  (I)  is  by  reducing  it  to  equality  (2)  via  a statement 
expressing  a kind  of  commutativity: 

(3)  SUBST(RC.ONS(A,B),S)  - RCONS(SUBST(A,$),TSUBST(B.S)) 

(the  change  from  SUBST  to  TSUBST  is  ecessary  because  of  the  different  type)  together  with 
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(4)  IF  <XI-X2)a('’I-Y2)  THEN  RCON$(X  i,Y  l)-RCONS(X2,Y2) 

as  a goal  statement  For  example,  look  at  th»  relevant  parts  of  V C»  10: 

SUBST(U,Z)-$UB$T(V,Z)  a TSUBST(HD(Y  l),Z)-TSUBST(HD(X  l),Z) 

-4  SUBST(RCONS(U,HD(X  l)),Z)=MJBST(RCONS(V,HD(YI)),Z) 

Using  the  statements  (3)  and  (4)  the  simplifier  will  generate  from  the  conclusion  the  subgoal 

RCONS(SUBST(U,Z),TSUBST(HD(Xl),Z))-RCONS(SUBST(V,Z),TSUBST(HD(YI).Z)) 

and  from  that 

SUBST(U,Z)”SUB$T(V,Z)  a TSUBST(HD(X  l),Z)-TSUBST(HD(Y  l),Z) 
which  is  just  the  premise 

Although  (3)  and  (4)  will  simplify  the  other  VC’s  further,  they  are  not  sufficient  to  reduce  them 
completely.  The  equality  in  VC.«4 

SUBST(RCONS(U,HD(X  l)),Z2«2)*SUBST(RCONS(V,HD(YI)),Z2»2)) 
will  be  reduced  to 

(5)  SUBST(U,Z2.2)-SUBST(V,Z2.2)  a TSUBST(HD(X  l),Z2.2)-TSUBST(HD(Y  l),Z2*2) 

Now,  the  first  conjunct  obviously  has  to  be  proved  from  the  equality 

(6)  SUBST(U.Z)  » SUBST(V.Z) 

in  the  premise.  This  raises  the  question,  how  Z and  Z2»2,  the  actual  value  of  Z I,  are  related  to 
each  other.  Looking  at  the  program  text  we  find  that  Z2  is  the  substitution  returned  by  the  call  to 
UNIFY  in  case  of  success;  thus,  12  is  an  extension  of  Z by  one  or  more  applications  of  COMP. 
To  express  this  relationship  we  introduce  the  predicate  IS$UBSUB(SI:$UB;  S2SUB)  meaning 
"SI  is  a sub-substitution  of  S2"  or  more  precisely  SI  is  an  initial  part  of  S2  (from  which  It  follows 
that  by  composing  SI  with  appropriate  singlesub's  we  can  get  S2).  We  can  now  formulate  a 
lemma  sufficient  to  reduce  the  first  equality  in  (b)  to  (6): 

IF  ISSUBSUB(Z,Z2)  a SUBST(U,Z)-SUBST(V,Z)  THEN  $UBST(U,Z2)=SUBST(V,Z2) 

provided  the  predicate  ISSUBSUB(Z.Zl)  is  added  to  the  exit  condition  of  UNIFY  and  therefore 
also  to  the  invariant  of  the  WHILE  loop. 

In  order  to  prove  the  second  conjunct  of  (5)  we  have  to  look  for  "similar"  equalities  In  the  premise 
of.VC«4  Obviously,  the  relevant  parts  are 

(7)  SUBST"rERMS(TSUBST(HD(Y  l),Z)),Z2«2)=SUBST(TERMS(TSUBST(HD(X  l).Z)),Z2*2) 
a FNLT(TSU BST(HD(Y  l),Z))-FNLT(TSU BST(HD(X  l).Z)> 


* CONSTRUCTING  A BASIS 

which  exactly  mean  that  TSUBST(HD(X  l).Z)  and  TSUBST(HD(YI),Z)  are  unified  by  Z2.2  If 

we  add  a;  a new  axiom  (no 22  in  figuie  8 (append, x))  the  cond.t.on  stating  when  two  functional 
terms  are  unified,  then  (7)  will  be  replaced  by  * functional 

(8)  TSUBST(TSUBST(HD(Y  l),Z),Z2»2)«TSUBST(TSUBST(HD(X  l),Z),Z2«2) 

rh'Pr0Jb'e‘"  now  is  ti°Prove  the  sccond  ^junct  of  (5)  from  (8).  This  is  a plausible  implication 
and  is  added  as  a goal  (no  16  in  figure  8)  * 

Similarly,  other  lemmas  are  derived  to  reduce  the  remaining  VC's  to  TRUE. 

The  third  version  of  the  top  level  program  is  shown  in  appendix  (figure  8)  Using  the  axioms 
and  goals  listed  m figuie  8 the  system  ,s  abie  to  reduce  all  the  verification  conditions  to  TRUE 
except  VC.2;  this  involves  more  complex  propositional  structure  and  is  proved  easily  by  the 
theorem  prover  Thus,  figure  8 contains  an  adequate  documentation  of  fhe  top  level 


3.4  ANALYSIS  OF  THE  VERIFICATION  BASIS.  The  basis  as  given  in  figure  8 is  adenu^te 
to  reduce  the  top  level  VC's  completely,  but  by  no  means  does  the  verification  of  the  program  end 
at  this  point.  Beside  axioms  about  data  structure  primitives  the  basis  contains  spcifications  on 
non-primitive  functions  and  lemmas  relating  these  functions.  r 

Analysis  of  the  verification  basis  is  intended  to  show  that  the  basis  is  acceptable,  that  is  we  can 
write  programs  for  the  second  level  functions  that  satisfy  the  DEFFUN's  and  the  lemmas  A fairly 
sensible  order  of  doing  this  is  the  following.  ' 

I)  Axioms  from  user-defined  data  structures  and  standard  properties  of  primitives  are  accepted 
21  AM  basis  statements  involving  only  primitives  must  be  derived  from  the  standard  properties 

3)  The  number  of  remaining  statements  involving  second  level  functions  is  reduced  by  finding 

dependancies  between  them.  1 & 

4)  Code  for  the  second  level  functions  is  written  to  satisfy  the  DEFFUN’s  and  the  remaining 

basiJ  specifications  ,ninB 

5)  If  a lemma  cannot  be  ratified,  ,t  must  be  changed.  This  in  turn  requires  establishing  the 

adequacy  of  the  altered  ba  is  for  verifying  the  top  level.  ® 

Following  this  scheme,  (refer, ng  to  figure  8 (appendix))  we  find  that  axioms  .1  and  .2  are  part  of 

atn,tVKPe  defin,t,T'  'N°'e  that  n°  l,s<?  was  made  of  other  data  ^ axioms  so  far.  hdwever 

Srrnp  ^ leVCl  funct,ons)  We  'he  functions  APPEND  and 

OCCUR  as  primitives  (standard  library  functions);  axioms  nos  3,1,6  are  standard  properties  of 

Obviously,  axiom  «l  I follows  immediately  from  axiom  *10  and  goal  «I2. 

AM  the  remaining  basis  statements  involve  second  level  functions.  They  obviously  cannot  be 

Til  "I'k6  * DEFFUN'S'  bu‘  P">™"  fnker  tpcafcajs  of  the  subfuncUo',' 

They  must  be  regarded^  necessary  conditions  that  the  programmer's  code  must  satisfy  In  this 

Jyi™y  Ser^c  as  >,d!  |;nps7or  the  wr,t,n&  of  sccond  ,evel  Programs;  some  of  them  - eg 
nos  9,10,13  • can  be  translated  directly  into  code  as  part  of  the  case  analysis. 
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For  some  of  the  functions  the  programs  are  staightforward.  Axioms  §5  and  #7  specify  RCONS-  If 
we  define  RCONS  by 

RCONS(X.Y) A PPEND(X.LIST(Y)) 

then  *5  follows  easily  from  well-known  properties  of  APPEND  and  LIST.  Taking  COMP  as  the 
abbreviation 

COMP(S.V.T)  - 4K:UB(S,PAIR(V,T)) 

the  lemmas  nos  8,9,10,  and  i2  give  the  obvious  pecification  of  ISSUBSUB  in  terms  of  MKSUB. 

In  appendix  figure  10  programs  for  the  secorJ  level  functions  are  given  which  correspond  to  the 
DEFFUN’s  used  at  the  top  ievel  The  verification  that  these  programs  satisfy  the  DEFFUN’s  can 
be  done  relative  to  a basis  consisting  of  the  data  type  definitions  (i.e.  axioms  and  DEFFUNS  for 
the  constructors  and  selectors)  This  is  straightforward  since  the  programs  directly  reflect  the 
recursive  nature  of  the  types 

Remark  It  should  be  noted  that  verification  basis  for  the  top  level  does  not  necessarily 
completely  predetermine  the  way  second  level  functions  have  to  be  implemented.  In  our  example, 
application  of  substitutions  can  still  be  either  simultaneous  or  sequential,  this  solely  depends  on 
the  representation  of  the  function  COMP  (or  MKSUB)  (Although  the  type  definition  for  SUB 
implies  sequential  application,  we  did  not  make  any  use  of  those  axioms)  The  implementation  in 
figure  10  assumes  sequential  application  of  substitutions. 

Now  we  must  show  that  the  programs  satisfy  the  rest  of  the  lemmas.  Usually,  proving  that  a 
lower  level  function  meets  a specification  (satisfies  a lemma  in  the  basis)  means  setting  up  a new 
verification  problem  by  adding  the  lemma  to  oe  justified  to  the  ENTRY  and/or  EXIT  assertions 
for  the  body  of  the  function.  In  complex  cases,  especially  where  the  proof  requires  induction  over 
a data  structure,  it  is  necessary  to  reduce  the  problem  by  hand  first.  (Data  structure  induction 
rules  are  not  implemented  yet ) 

A;  an  example,  we  show  the  justification  of  the  goal  • 1 5,  us;ng  the  programs  from  figure  10. 
First,  goal  *15  was  reduced  using  the  induction  rule  for  the  data  type  SUB  to  the  induction  step 
problem  (the  base  case  problem  is  trivial)  This  problem  in  turn  was  fuither  simplified  by  hand  to 
(15’)  using  properties  of  ISSUBSUB  and  the  assumption  of  the  induction  step 

(15’)  lSSUB(SI)  a ISSINGLESUB(S2) 

a TSU BST(L,  MKSUB(Si,  S2))  - SINCLETSUBST(TSUBST(L,  SI),  S2) 

If  (15’)  can  be  verified,  then  we  can  use  induction  to  prove  goal  «I5,  Figure  II  (appendix)  shows 
the  verification  of  (15') 

Perhaps  the  reader  may  be  convinced  that  the  proofs  of  all  the  remaining  lemmas  in  figure  8 (see 
Appendix)  are  as  straightforward  as  «15.  Hence  figure  8 presents  an  adequate  and  acceptable 
basis  (i.e.  the  lower  level  functions  can  indeed  be  coded  to  satisfy  the  lemmas).  The  top  level 
then  Is  verified 

This  is  not  so 
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Coal  .16,  although  simple  enough,  hides  (i.e.  depends  upon)  an  extra  property  of  the  top  level 
hat  has  not  yet  come  to  light.  It  is  not  true  of  substitutions  in  general,  thus  it  is  not  acceptable  in 
"h'r  * t,Ue,°f  thC  Mlb5t,,ut,or"  instructed  by  the  program  (which  Is  why  it  was 

hand  Vsidee  beca,,se  lh*\  havc  a property.  Namely,  whenever  a variable  occurs  al  the  left 
hand  side  of  a pair,  it  will  not  occur  in  any  later  pair  This  property  holds  for  these  substitutions 
because  whenever  a substitution  for  a variable  is  added  to  Z.  that  particular  variable  is  el  mma^d 
from  all  expressions  remaining  in  XI  and  Yl  (by  then  applying  Z).  The  property  is  equivalent  s 
Idempotency  of  the  substitution  which  we  express  by  the  new  predicate  HIDEM(S)" 

IDEM(S)  - SUBST(X.S)  ■ SUBST($UB$T(X,S),S)  for  all  X. 

We  must  change  goal  .16  to  goal  »I6NEW  by  adding  IDEM(Z)  to  it  as  a premiss  and  then  start 
erifkation  of  the  top  level  again  (see  step  5,  beginning  Section  M).  Reasoning  along  the  lines 
developed  in  earlier  sections  (and  analysis  of  the  new  VC's)  shows  that  we  have  to  expand  al 
assertions  in  the  program  by  appropriate  instances  of  IDEM  (see  figure  12).  Analysis  of  the  VC's 
shows  that  one  additional  lemma  is  required:  ' 

IDEM(SI)  a IDEM(COMP($l,T$U BST(X ,S I ),TSU BST(Y.S I ))) 

We  add  this  to  the  basis  (goal  .I6A)  and  obtain  again  a complete  reduction  of  the  top  level  VC’s. 


ENTRY  ISTERMLIST(X)aISTERMLIST(Y)aISSUB(Z1)aIDEM(ZI  )• 

EX'T  vS(FLAGZ!  J)!SUBST(X-Z,*SUBST<V»  * ISSUBSUB(Zl’z)  a IDEM(Z)  a (FLAG.) )) 


INVARIANT  (..  a(APPENO(V,YI  WaISSUBSUBKI  ,Z)  a IDEM(Z)  a (FLAG-I))  v (FLAG-0) 

T.  ! 5NEW  7 GOAL  TSUBST(oX,oZ)»TSUBST(oY,«Z) 

SUB  ISSUBSUB(»S,Z)  a IOEM(oS) 

a (TSUBSTfTSUBSTfX.fflSLZKSUBSTfTSUBSTfY.eSJ.Z)); 

7 I6A  7 GOAL  IDEM(COMP(»SI  ,TSUBST(oX,«SI  ),TSUBST(oY,fflSI )))  SUI)  IDEM(Sl); 

Figure  12:  Expanded  documentation  for  idempotency 


The  additional  lemma  .I6A  can  be  justified  by  showing  that  it  is  derivable  from  standard 
properties  of  substitution  composition  and  application.  (This  proof  is  given  in  the  anoendi*  y 
This  means  that  it  will  be  satisfied  by  correct  code  for  COMP  and  TSUBST  ^ 
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3.5  VERIFICATION  OF  FURTHER  PROPERTIES  Or  UNIFY.  When  the  user  has 
developed  an  adequate  documentation  for  his  prop, rams  with  respect  to  one  property  he  can 
attempt  to  exploit  it  for  the  verification  of  fuither  properties  In  this  section  we  demonstrate  how 
additional  verification  problems  can  be  solved  by  modifying  the  established  basis  and  assertions 

The  basis  developed  at  the  end  of  section  3.4  (figures  8 and  12)  is  adequate  for  verifying  a rather 
weak  property  of  our  unification  program  However,  even  this  task  has  brought  to  I, eht  the 
unusual  and  useful  idcmpotency  property  of  the  substitutions  constructed  by  this  program*  Now 
when  we  come  to  verify  more  stringent  requirements  we  find  further  code  changes  to  be  necessary’ 
and  these  are  justifiabe  by  idenipotency  ’’ 

Our  goal  is  to  verify  tliai 

"ESS  if  the  lermlmf  ptmrf  * argummu  are  u„,fiable; 

ab)  UNIFY  retuins  FLAG"0,  i.e  failure,  mily  if  the  termlists  are  not  umfiable 

In  order  to  prove  (a)  we  mtioduce  a predicate 


MCU(X.Y.Z)  - 


"S  15  a most  general-unifier  (or  mgu,  for  short)  of  X and  Y.  i.e.  S is  a 
substitution  that  unifies  X and  Y,  and  if  S’  is  another  unifier  for  X and  Y 
then  S is  a sub  substitution  of  S'." 


First  of  all.  assertions  in  the  prog. am  are  strengthened  by  replacing  all  occu  rences  of  eauations 
of  the  form  SU  BST<p>.SUBST<Y,S)  by  MCWXXSl  We  cannot  make  a L'l^ZZ. 
minded  strengthening  of  the  basis  since  some  goal  statements  are  not  true  if  all  of  the 

are  Iestr,cwd  t0  beill8  mStls  w*  must  find  out  what  properties  of  MGU  need  to  be 
added  to  the  existing  basis  We  therefore  return  to  the  verifier  and  try  to  derive  the  necessary 
axiomatization  for  MGU  from  the  VC's.  J necessary 

The  first  problem  arises  from  a VC  corresponding  to  the  path  from  ENTRY  to  INVARIANT 
which  is  of  the  form 

l$TERMLIST(XM$TERMLIST(Y)  a ISSUB(ZI)  - MGU(ZERO,  ZERO.  Zl) 

This  can  only  be  true  if  ZhZF.RO  (see  case  (m)  in  section  2.4)  Now.  Zl  is  a value  parameter 
So  we  must  ask  if  Z I can  be  eliminated  from  the  body  of  the  procedure.  ^ 

This  leads  us  io  consider  the  path  containing  the  recursive  call  to  UNIFY,  and  here  we  find  in 
general  th'.t  Zl^ZERO  The  recursive  call  is  of  the  form 

l NIFY(TERMS(X2).  TERMS(Y2).  Z.  Z2.  FLAG) 

where  X2-TLU  BST(HO(X  I).  Z)  and  Y2.TSUBST(HD(Y  I).  Z),  and  the  current  value  nf  Z 

o X iVnTv  P|frwT  Zl,  N°‘ICe  tha‘  X2  and  Y2  arP  Valt,eS  re5U,,,n?  flom  »PPHe.l»  ns 
of  Z to  X I and  Yl.  If  we  race  the  computation  of  this  call,  we  find  that  the  only  use  made  of  Z 

e value  of  Zl)  is  n apply  it  again  to  X2  and  Y2.  By  idcmpotency,  this  second  application  is 

redundant  Thus,  if  we  omit  the  parameter  Zl  altogether  and  initialize  Z to  ZERO,  we  get  exactly 

1m  ? T TU  Lby  aPPr°Pr'ate|y  COIT,posing  the  substitution  returned  by  the  recursive  call  with  the 
old  Z.  To  do  this,  we  introduce  a general  composition  function. 
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further  properties  of  unify 


SC.OMP(Z  I.Z2)  - the  composition  of  two  substitutions,  Zl  and  Z2 

It  turns  out  that  the  verification  can  now  be  completed  bv  adding  ,„„i  i 

describes  how  to  build  up  mgu’s  ^ y g one  crucial  new  axiom  which 


(:■) 


MGU(X  I.YI.SI)  a MGU(TSUBST(X2.$  I),  TSUBST(Y2SI)  S2) 
M C U( R CON S(X  I ,X 2),  R CONSf Y I ,Y2).  SCOM  P(S  I ,S2))  ' 


(goal  «26  in  figure  I?)  If  we  lenlace  the  old  f'OMD/7vv\  l. 

’p““' casc  * w ^ •”> «» --i  T^'Z 

ror  acceptability,  we  give  a Jimitaion  of  ,he  no,  loimed.aiel,  obv,„u,  lemn,a  “ ,he  ^pendiv 

Remark:  Having  made  these  changes  (justified  on  the  basis  of  Idempotencv)  the  re»nn  r 

having  to  verify  idempotency  in  the  old  code  disanr»rir«  ^ reason  for 

s“„c;npcb„'pe::;,fi'd  w"hou' « <sm  ^ 1 31 
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7.  Goals  lor  MGU  7, 

7.  26  7.  GOAL  MGU(RC0NS(«XI  ,c5X2),RC0NS(bY11®Y2)1  SC0MP(®S1  0$2)) 

SUB  MGU(XI,YI,SI)aMGU(TSU0ST(X2,SI)1TSUBST(Y2,SI),S2); 

7 27  7.  GOAL  MGU(RCONS(fPX I ti3X2),RC0NS(nYI  ,qY2),  MKSUB(eSI  BS2)) 

SUB  MGU(Xi  ,YI  ,SI  )aMGU(TSUBST(X2,SI  ),TSUBST(Y2,S1  ),S2); 

7.  28  7.  GOAL  MGU(RCONS(»XI  lnX2),RC0NS(oYl1i9Y2)1oSI ) 

SUB  MGU(XI  ,Y  I ,$  I )a(T$UBST{X2,SI  )«TSUBST(Y2,SI )); 

7.  29A  7.  GOAL  MGU(®X.oY,PAIR(«3X,qY))  SUB  ISVAR(X)aISTERM(Y)a-OCCUR(X  Y)- 
7 29B  7.  GOAL  MGU(«X,nY,PAIR(oYpnX))  SUB  ISVAR(Y)aISTERM(X)a*OCCUR(y'x)’ 

7.  30  7.  GOAL  MGU(«X,<sY,nS)  SUB  (FNLT(X)*FNLT(Y))aMGU(TERMS(X),TERM$(Y)  S)* 
7.  31  7.  AXIOM  MGU(ZERO, ZERO, ZERO-TRUE;  1 h U 


DEFFUN  MKSUB(S:SUB;  S I :SINGL£SUB):  SUB; 

ENTRY  ISSUB(S)aISSINGLESUB(SI  );  EXIT  ISSU-I(MKSUB); 

DEFFUN  PAIR(X:VAR;  Y:TERM);  SINGlESUQ; 

ENTRY  ISVAR(X)aISTERM;Y)a-OCCUR(X,Y>;  EXIT  ,SSINGLESUB(PAIR); 

DEFFUN  SCOMP(SI,S2:SUB):SUB;  ENTRY  ISSUB(S  I )aISSUB(S2);  EXIT  ISSUB(SCOMP); 

PROCEDURE  UNIFY(X,Y;TERMLIST;  VAR  Z;SUB;  VAR  FLAGdNTEGER)- 
ENTRY 

EXIT  (ISSUB(Z)  a MGU(X,Y,Z)  a (FLAG*!))  v (FLAG*0); 

BEGIN 

7.  Initialization  of  variables  7. 

. . . ZlZERO;  . . . 

INVARIANT  (ISSUB(Z)aISTERMLIST{U)aISTERMLIST{V)aISTERMLIST(XI) 

a ISTERMUSTtY!  lAMGUfU.V.ZWX.APPENDfU.X  1 ))a;Y*APPEND(V,YI  ))a  (FLAG-1 )) 
v (FLAG=0) 


WHILE  DO 
BEGIN 

IF  ISVAR(X2)  THEN  BEGIN  IF  ISVAR(Y2) 

THEN  BEGIN  IF  (X2/Y2)  THEN  r;>MKSUB(Z,PAIR(X2,Y2)) 
END 

ELSE 

END 

ELSF  BEGIN  IF  ISVAR(Y2)  THEN 

ELSE  BEGIN  IF  FNLT(X2 )=FNLT(Y2) 

THEN  BEGIN  UNIFY<TERMS(X2),TERMS(Y2),Z2,FLAG); 

IF  FLAG* I THEN  Z:*SC0MP(Z,Z2) 

ELSE  FLAG:*0 
END 

ELSE  . . . 


Figure  13:  Additional  documentation  and  program  changes  for  MGU 
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FURTHER  PROPERTIES  OF  UNIFY 


Problem  (b)  is  to  show  that  if  UNIFY  returns  FLAG-0  then  there  is  no  unifier  for  X and  Y. 
We  express  this  property  by  the  predicate: 

NOTUNIF(X.Y)  - "X  and  Y are  not  umfiable" 


and  set  up  the  new  verification  problem 

j UNIFY(X.Y,Z.FI  AG)  } ( . . *FLAG»I)  V (FLAG-0  a NOTUNIF(X.Y)) 

Note  that  the  post-condition  implies  " FLAG-1  <->  NOTUNIF(X.Y)  The  adequate 
axiomatizatiou  of  NOTUN1F  is  a.most  straightforward.  However,  in  goals  and  «.4  (see  figure 
14}  the  premiss  MGU(  ) is  ciucial  for  acceptability 

The  final  program  and  documentation  for  the  full  verification  of  UNIFY  is  given  in  figure  14. 


ACKNOWLEDGEMENTS,  We  wish  to  acknowledge  the  efforts  of  M.  Slntzoff  in  helping  to  set  up 
this  experiment  at  the  beginning  N.  Suzuki  has  cooperated  at  all  stages  In  modifying  the 
simplification  system  to  handle  our  problems, 


v HENKE  and  LUCKHAM 


30 


REFERENCES 

[Boyer  and  Moore]  R.S  Boyer  and  J S.  Moore,  "Pro  >ng  Theorems  about  LISP  Problems', 
Third  IJCAI  Proceedings,  1973. 

[Clint]  M.CImt,  "Piogram  Proving  Coroutines",  Acta  Informatica  2 (1973),  52-63. 


[Deutsch]  LP  Deutsch,  "An  Interactive  Program  Verifier",  PhD.  thesis,  University  of 
California,  Berkeley,  197? 

[ELW]  B Elspas,  K Levitt,  and  R Waldmger,  "An  Interactive  System  for  the  Verification  of 
Computer  Programs",  SRI  Project  1891,  Stanford  Research  Institute,  1973. 

[Floyd]  R.W  Floyd.  "Algorithms  245.  TREESORT3",  Comm  ACM  7 (1964) 


[Good  and  Ragland]  D.  Good  and  L.  Ragland,  "NUCLEUS  - A Language  of  Provable 
Programs",  in  Program  Test  Methods,  W.Hetzel  (ed.),  Prentice  Hall,  1973. 

[Hoare  71]  C A R Hoare.  "Procedures  and  parameters:  An  axiomatic  approach",  in  Symposium 
on  Semantics  of  Algorithmic  Languages,  Engeler,  E.  (ed),  Springer-Verlag,  1971,  pp.102- 

1 16 


[Hoare  1973]  C.A  R Hoare,  "Recursive  data  types",  Memo  AIM-223,  Stanford  Artificial 
Intelligence  Project,  Stanford  University,  1973. 

[Hoare  and  Wirth]  CAR.  Hoare  and  N.  Wirth,  "An  Axiomatic  Definition  of  the 

Programming  Language  PASCAL",  Acta  Informatica  2 (1973),  335-355. 

[ILL]  S.  Igarashi.  R L.  London,  and  DC.  Luckhani,  'Automatic  Program  Verification  I:  Logical 
Basis  and  Its  Implementation",  AIM-200,  Stai  ford  Artificial  Intelligence  Project,  Stanford 
University,  1972. 

[King  and  Floyd]  JC.  King  and  R.W  Floyd,  " An  Interpretation  Oriented  Theorem  Prover 
over  the  Integers".  Journal  of  Comp,  and  SysSci , vol  6,  no.4,  Aug.  1972  pp.305-323. 

[McCarthy]  J McCarthy,  "A  basis  for  a mathematical  theory  of  computation",  in  Computer 
Programming  and  Formal  Systems,  (ed.  Braffort  and  Hirschberg),  North  Holland,  1963. 

[Morales]  J.  Morales,  "Verification  of  Sorting  Algorithms",  unpublished  report,  Sept  1973. 

[Suzuki]  N Suzuki,  "Verification  of  Programs  by  Algebraic  and  Logical  Reduction",  forthcoming 
Memo,  Stanford  Artificial  Intelligence  Project,  Stanford  University. 


[Wirth]  N.  Wirth,  "The  programming  language  Pascal",  Acta  Informatica  l.l  (1971),  35-63. 


3l> 


APPENDIX 


APPENDIX 


Proofs  of  lemmas 

Figure  8 Third  version  of  top  level  ♦ corresponding  goalfile 
Figure  9 Sample  VC’s  for  third  version 
Figure  10:  Second  level  ft  nctions  ♦ goalfile 
Figure  II  Lemma  about  ^oal  15 

Figure  If.  The  complete  p.ogram  and  documentation  for  UNIFY 


Proofs  of  Lemmas 

Notation:  We  use  the  following  short  hand  notation. 

"x.oc"  for  substitution  application  (TSUBST/SUBST) 

"oce/T  for  substitution  composition  (MKSUB/SCOMP) 

"x':y"  for  list  concatenation  (APP/RCONS) 

“<x.y>"  for  PAIR(X.Y) 

We  make  use  of  certain  facts  about  substitutions. 

(I)  associativity  of  V:  oc  lo(oc2*o<3)  - (ocl*oc2)*oc3 
(ii)  a k-nd  of  associativity  of  (x.oCl).oc2  - x.(ocl*oc2) 

(ill)  a kind  of  dlstributivity  of  (xcy).o i • (x.ocWy.o i) 


I.  Coal  I6A:  IDEM(oc)  -4  IDEM(oC»<x.oC,  y.*>) 

This  Is  equivalent  to  proving 

(oc  • <x.cc,  y oc>)  • (c<  • <x.oc,  y.oC>)  - oc  • <x.o<,  y.oC> 
from  the  assumptions 


(al)  oc*oc-oC.  (a2)  Isvar(x.oc),  (a3)  isterm(y.oc),  (a<)  ->  occur(xxrt,y.oO 

(a2)-(af ) are  from  the  ENTRY  assertion  for  COMP;  they  imply  that  the  single 
substitution  Is  idempotent,  namely 


(b)  <x.oC,  yoC>  « <x,oc,  y oi>  - <x.oC,y.oC> 
Now 

(oc  • <x.oc,  yoc>)  • (<*  * <x.oc,  y.oc>) 

- ((oc  • <x  oc,  y .<*>)  « cc)  « <x  oc,  y.oc> 

- [(oC  • oc)  • <X.oC,  y.(oC*oC>)]  • <X.oC,  y.o c> 

■ [oi  • <x.o i,  y.oc>]  • <x.oct  y.oc> 

■ u • <x.oC,  y.o c> 


by  (I) 

using  standard  properties 
of  and  V and  (al) 
by  (a) 
by  (b),  (I) 
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2.  LEMMA  H for  MCU  (Section  15) 

(••')  MGU(X  I.Yl.oc  I)  a MGU(X2<y !.  Y2.ocl.  <*2)  3 MGU(X  1 .>X 2.  Y l*Y2,  oc  |®oc2) 

We  prove  (")  from  the  assumptions 

(1)  MGU(\  I .Y I ,oC  I) 
and 

(2)  MGU(X2.r/|,  Y2c<l.c<2) 


Suppose 
Then  by  (I) 
so 

which  implies 
From  this  we  infer 
Thus,  by  (2) 
or 

for  suitable  /32.  which 


(XbX2)/?  - (Y I Y2 )./l 
/l  * ?<.  I f'/l  I 

(X  1X2)  (-<  l<-/3|) . (Yl  Y2)(oc|o/3l) 
t(Xl.ocl)  (X2.*l)]/*l  - [(Yl.oc  I)  (Y2.oc  |)]./3 1 
(X2 <y  l ) /3 1 - (Y2.oc  i)/3 1 
1 31  - oc2°fl2 
(!>  - (ocl<?>c*2M2 
proves  ( ) 


for  suitable  /3 1, 
by  (ii).  (ill) 
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•'  APPENDIX 

GOALFI'.E 

7 Axioms  defining  lh«  data  lypos  and  basic  (unctions  7. 

7.  1 7.  AXIOM  ISTERMLIST (ZERO)  « TRUE; 

7 2 7 AXIOM  l$SUB(ZERO)«TRU£; 

7 Axioms  doscribmj  properties  o ( subfunctions  7. 

7.  3 7 AXIOM  APPENO(ZERO,(5S)“S; 

7 4 7 AXIOM  APPEND{®S,ZERO)«S; 

7 5 7.  AXIOM  APPEND(RC0NS{OS,HD(oT)),TL(BT))»*APPEND(S,T); 

7 6 7.  AXIOM  IF  ISVAR(X)aISVAR{Y)a(Y/X)  THEN  'OCCUR(oX,ttY)«TRUE{ 

7.  7 7.  GOAL  RCONS(eXI,oX2)*RCONS(BYl,flY2)  SUB  (X1»Y1  )a(X2«Y2); 

7 8 7 AXIOM  IF  ISSUB(Z)  THEN  ISSUBSUB(ZERO,oZ)«TRUE; 

7.  9 7 AXIOM  ISSUBSUB(«Z,«ZWRUE; 

7.  10  7.  AXIOM  ISSUBSUBfraZ.COMPtoZ.raX.raYJWRUE; 

7.  I I 7.  AXIOM  IF  ISSUDSUG(Y,2)  THEN  ISSUBSUB(.-SY,COMP(oZ,oV,oW))hTRUE| 

7.  12  7.  GOAL  ISSUBSUBduZ.raZl)  SUB  ISSUQSUB («22,ZI )aISSUBSUB(2pbZ2) 

ISSUBSUB(Z,bZ2)aISSUBSUB(bZ2,ZI  ); 

7.  13  7.  AXIOM  TSUBST(bX,ZERO)«X; 

7.  14  7.  AXIOM  IF  -ISVAR(X)  THEN  -ISVAR(TSUBST<eX,o$))»TRUE; 

7.  15  7 GOAL  TSUBST(»X,«Z)>TSUBST(eY,oZ)  SUB  ISSUBSUBIbZI  ,Z)a(TSUBST(X,bZI  )-TSUBST(Y,bZI  )) 

7 16  7.  GOAL  TSUBST(«X,®Z)*TSUBST(»Y,raZ) 

SUB  ISSUBSUB(csS,Z)A(TSUOST(TSUBST(XtoS),Z)*TSUBST(TSUBST(YpoS),Z)); 

7.  17  7.  GOAL  TSUBST{®X,COMP(qZ,®X,«Y))=TSUBST'«Y,COMP(bZ,BX,bY)) 

SUB  ISSUB(COMP(Z,X,Y)),  ISSUB(COMP(Z,Y,X»; 

7 18  7 GOAL  TSUBST(®X,COMP(®Z(®U,®V))sTSUBST(«Y,COMP(bZ,|»U,BV)) 

SUB  (U*TSUBST(X,Z))a(V«TSUBST(Y,Z))aISSUB(COMP(Z,U,V)), 
<U-TSUBST(Y,Z))a(V-TSUOST{X,Z))aISSUBCCOMP(Z,U,V)); 


Figure  8 (continued) 
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1 19  1 AXIOM  $UPST(oX,ZERO)«X; 

1.  20  7.  AXIOM  SUBST(ZERO,*>S)»ZERO; 

7.  21  7 AXIOM  SUBSKRCONSIoX.wYJ.oZHRCONSISUBSKX.ZUSUBSKY.Z)); 

7 22  7.  AXIOM  IF  FNLT(X)=FNLT(Y)  THEN  (SUB$T(TERMS(nX),fiZ)*SUBST(TERMS(©Y),«Z)).. 

(TSUBST  (X,Z)*TSUBST(Y,Z)); 

7.  23  7.  GOAL  $UBST(i9X,C0MP(rtZ,f9A,oB))=$UBST(sY,::0MP(©Z,®A,BB)) 

SUB  (SUBST(X,Z)=SUBST(Y1Z))aISSUB(COMP(Z,A,B)); 

t 24  7.  GOAL  SUBST(oX,oZ)3SUBST(©Y,«Z)  SUB  I$SUBSUB(bZI,Z)a(SUBST{X,©ZI  )=SUBST(Y,©ZI 
PASCAL 

DEFFUN  HO(L:TERMUST):TERM;  ENTRY  ISTERMLIST{L)a-(L«2ER0);  EXIT  ISTERM(HD); 

DEFFUN  TL(L:TERMLIST):TERMLIST ; ENTRY  I$TERMLI$T(L)a*(L»ZERO);  EXIT  ISTERMLIST(TL); 

DEFFUN  RCONS(L:TERMLIST;  X:TERM):TERMLIST; 

ENTRY  ISTERMLIST (L)aISTERM(X);  EXIT  ISTERMLIST(RCONS); 

DEFFUN  TERMS (X:TERM):TERMLIST;  ENTRY  ISTERM(X)a*ISVAR(X);  EXIT  ISTERMLIST(TERMS); 

DEFFUN  FNLT(X:TERM):CONST;  ENTRY  ISTERM(X)a-I$VAR(X);  EXIT  ISCONST(FNLT); 

DEFFUN  TSUBST(X:TERM:S:SUB):TERM;  ENTRY  ISTERM(X)aISSUB(S);  EXIT  ISTERM(TSUBST); 

DEFFUN  SUBST(X:TERMLIST;  S:SUD):TERMUST; 

ENTRY  ISTERMLIST (X)aISSUB(S);  EXIT  ISTERMUST(SUBST); 

DEFFUN  COMP(S:SUB;  X:VAR;  Y:TERM):SUB; 

ENTRY  ISSUB(S)aISV  \R(X)aISTERM(Y)A'OCCUR(X,Y);  EXIT  ISSUB(COMP); 

DEFFUN  OCCUR (X:VAR;  Y:TERM):BOOLEANj  ENTRY  I$VAR(X)aISTERM(Y);  EXIT  ISBOOLEAN(OCCUR)} 


Figure  8 (continued) 
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PROCEDURE  UNIFY (X ,Y:TERMLIST ; ZI-.SUD;  VAR  ZiSUB;  VAR  FLAGiBOOLEAN); 

ENTRY  ISTERMLIST(X)MSTERWLIST(Y)aISSUB(Z1); 

EXIT  (ISSU0(Z)A(SUBST(X,Z)*SUBST(Y,Z))/MSSUBSUB(Z1  ,Z)a{FLAG-1  ))  v Tl  AG  ■ 0); 

VAR  U,V,X  I ,vl  .-TERWLIST;  VAR  X2,Y2;TERM;  VAR  Z2:SUB: 

BEGIN 


7.  Initialization  of  variables  1 

U-.-ZERO;  VlZERO;  Z:=Z1;  X1:«X;  Y1  :=Y;  FLAG:*  1 ; 

INVARIANT  {ISSUB(Z)aISTERWLIST(U)aISTERMLIST(V)aISTERWLIST(XI)aISTERWLIST(YI  )a 

(SUBST(U,Z)=SUBST(V,Z))a(APPEND(U,XI  )sX)a(APPEND(V,YI)«Y)aISSUBSUB(ZI,Z)a(FLAG»1  )) 

v (FLAG=0) 

WHILE  (XI /ZERO)  a (Yl /ZERO)  a (FLAG=I ) DO 
BEGIN 

X2:»  TSUBST(HD(X1),Z); 

Y2:*  TSUBST(HD(YI  ),Z); 

IF  ISVAR(X2)  THEN  BEGIN  IF  ISVAR(Y2) 

THEN  BEGIN  IF  (X2/Y2) 

THEN  Z:«COMP(Z,X2,Y2) 

ENO 

ELSE  BEGIN  IF  OCCUR(X2pY2)  THEN  FLAG.-O 
ELSE  Z:*COMP(Z,X2,Y2) 

ENO 

END 

ELSE  BEGIN  IF  ISVAR(Y2) 

THEN  BEGIN  IF  OCCUR(Y2,X2)  THEN  FLAG  :-0 
ELSE  Z:*COMP(Z,Y2,X2) 

END 

ELSE  BEGIN  IF  FNLT(X2)*FNLT(Y2) 

™EN  BEGIN  UNIFY(TERMS(X2),TERMS(Y2),Z,Z2,FLAG); 

IF  FLAG-1  THEN  Z:«Z2 
END 

ELSE  FLAG:*0 
END 

END; 

U :=RC0NS(U,HD(X1 ));  V :=RCONS (V,HD(Y I )); 

X 1 :=TL  (X 1 );  Y1  :=TL(Y1 ); 

END;  7.  End  of  WHILE  body  7. 

IF  (X| /ZERO)  v (Yl/ZERO)  THEN  FLAG:=0 
END;  1 Procedure  body  7. 


Figure  8:  Third  version  with  documentation 


v HENKE  and  LUCK  HAM 


FOR  UNIFY  THERE  ARE  I I VERIFICATION  CONDITIONS.  HER.-  IS  ONE  OF  THEM: 

« 4 

(-XHZERO  £ ->Y I =ZERO  £ FLAGH  £ 

ISSUB(Z)aISTERMLIST(U)aISTERMLIST (V)aISTEPMLIST(XI  )/\ISTERMLIS’f(YI  )a$UBSw 
T(U,Z)=SUBST(V,Z)aAPPEND(U,XIKXaAPPEND(V,YI)=YaISSUBSUB(ZI  Z)aFuAG»IvFLAG»0 
-*  ISTERMLIST(XI)  £ -XU  ZERO  £ (IS TERM(HD(X I )) 

-*  ISTERM(HD(X  I ))  £ ISSUR(Z)  £ (ISTERM(TSUBST(HD(X1  ),Z)) 

-»  ISTERMLIST(YI ) £ -YUZERO  £ (ISTFRM(HD(YI )) 

-»  ISTERM(HD(YI ))  £ ISSUB(Z)  £ (ISTCRM(TSUBST(HD(YI  ),Z)) 

-♦  (-ISVAR(TSUBST(HD(Y  I ), Z ))  £ -ISVAR(TSUBST(HD(X  I ),Z)) 

-*  ISTERM(TSUOST(HD(YI  ),Z))  £ -ISVAR(TSUBST(HD(YI  ),Z))  £ 
(ISCONST(FNLT(TSUBST(HD(Y!),Z))) 

-*  ISTERM(TSUG$T(HO(X  I ),Z ))  £ -ISVAR(TSUB ST(HD(X  I ),Z))  £ 
(ISCONST(FNLT(T$UG$T(HD(X  I ),Z))) 

-»  (FNLT (TSUBST (HO(X  I ),Z ) )-F NLT (TSUDST(HD(Y I ),Z)) 

-»  ISTERM(TSUUST(HD(YI  ),Z))  £ -ISVAR(TSUBST(HO(Y  I ),Z))  £ 

(1ST  FRMLIST  (TERMS  (TSUBST  (IID(YI  ),Z))) 

-»  ISTERM(TSUBST(HD(XI  ).Z)>  & -ISVAR(TSUBST(HD(X  1 ),Z>)  £ 
(ISTERMLI3T(TERMS(TSUBST(HD(XI),Z))) 

-*  ISTERMLIST (TERMS (TSUBST (HD(X  1 ),Z)))  £ ISTERMUST(TERMS(TSUBST(HD(YI  ),Z)))  £ 
ISSUB(Z)  £ (FLAG-1  £ 

ISSUB(Z2“2)aSUBST(TERMS(TSUBST(HD(X]  ), Z)), Z2*2 )=S UBST (TERMS (»' 
TSUBST(HD(Yl  ),Z)),Z2*2)aISSUBSUB(Z,Z2*2)aFLAGsI  vFLAG*0 
-*  ISTERMLIST (X I ) £ -XUZERO  £ (ISTERM(HD(X1 )) 

-»  ISTERMLIST (U)  £ ISTERM(HD(XI ))  £ (ISTERMLIST (RCONS(U,HD(X  1 ))) 

-*  ISTERMLIST(YI)  £ -v!-ZFRO  £ (ISTERM(HD(YI )) 

-*  ISTERMLIST(V)  £ ISTERM(HD(Y1 ))  £ (ISTERMLIST(RCONS(V,HD(Yl ))) 

-*  ISTERMLI3T(XI)£  -XUZERO£  (ISTERMLIST (TL(X  I )) 

-»  ISTERMLIST (Yl ) £ -YUZERO  £ (ISTERMLIST (TL (Y I )) 

-*  ISSUB(Z2»2)aISTERMLIST(RCONS(U,HD(X  I )))aISTERMLIST(RCONS(VpHD(YI  ) ) ) a 
ISTERMLIST(TL(X  I ) ) aISTERMLIST(TL (Y I ))a 
SUBST  (RCONS(U,HD(X  1 )),Z2«2)=SUBST(RCONS(V,HD(YI  )),Z2«2)a 
APPEND(K’CONS(U,HO(X  I )),TL(X  1 ))=Xa 
APF'END(RCONS(V,HD(YI  )),TL(Y  1 ))=Ya 
ISSI'BSUB(Z1  ,Z2«2)aFLAG=I  vFLAG=0)))»))))))))))))> 


Figure  0:  One  of  j lie  misimplified  VC’s  for  the  third  version 
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APPENDIX 


J7- 


GOALFILE 

AXIOM  ISTERMLIST(ZTRO)  » TRUE; 

AXIOM  ISSUB(ZERO)  « TRUE; 

AXIOM  ISSINGLESUB (ZERO)  « TRUE; 

GOAL  ISSINGLESUS(OS)  SUB  ($--PAIR(  3X,«5iY))AlSVAR(fflX)AlSTERM(fiY)A*OCCUR(oX,eY);.; 


PASCAL 

DEFFUN  MKTERM(X:CONST;Y:TERMLIST):TERM; 

ENTRY  ISCONST(X)  a ISTERMLIST ( Y >;  EXIT  ISTERM(MKTERM); 

DEFFUN  FNLT(X:TERM):CONST; 

ENTRY  ISTERM(X)  a -ISVAR(X);  EXIT  ISCONST(FNLT); 

DEFFUN  TERMS (X:TERM):TERMLIS'i ; 

ENTRY  ISTERM(X)  a -ISVAR(X);  EXIT  ISTERMLIST  (TERMS); 

DEFFUN  CONS(X:TERM;  L:TcRMLI$T):TERMLI$T; 

ENTRY  ISTERM(X)aISTERMLIST(L);  EXIT  ISTERMLlST(CONS); 

DEFFUN  HD(L:TERMLIST):TERM; 

ENTRY  ISTERMLIST(L)a-(L=ZERO);  EXIT  ISTERM(HD); 

DEFFUN  TL(L:TERMLIST):TERMLIST; 

ENTRY  ISTERMLIST(L)a-(L=ZERO);  EXIT  ISTERMLIST (TL); 

DEFFUN  MKSUB(S:SUB;  SI  :SINGLESUB);SUB; 

ENTRY  ISSUD (S JaISSINGLESUD (S I );  EXIT  ISSUOfMKSUB ); 

DEFFUN  LAST($:SUB):$INGLESUB; 

ENTRY  ISSUB(S);  EXIT  ISSINGLE?UB(LAST); 

DEFFUN  REST(S:SUB):$UB; 

ENTRY  ISSUB(S);  EXIT  ISSUB(RES . ); 

DEFFUN  VAR(S;SINGLESUB):VAR; 

ENTRY  ISSINGLESUB(S);  EXIT  ISVAR(VAR); 

DEFFUN  TERM(S:SINGLESUB):TERM; 

ENTRY  ISSINGLESUB(S);  EXIT  ISTCRM(TERM); 

DEFFUN  PAIR(X:VAR;  Y;TERM):PAIR; 

ENTRY  ISVAR(X)aI5TERM(Y);  EXIT  ISPAIR(PAIR); 

Figure  10  (continued) 
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FUNCTION  SUBST(L:TERMLIST;  S:SUB):TERMLIST; 

ENTRY  ISTERMLIST(L)  a ISSUO(S); 

EXIT  ISTERMLIST(SUBST); 

BEGIN 

IF  (S-2ERO)  THEN  SUBST:=L 

ELSE  SUBST:»SINGLESUBST(SUBST(L,REST(S)),LAST(S)); 
END; 


FUNCTION  TSUBST(X:TERM;  S:SUB):TERM; 

ENTRY  ISTERM(X)  a ISSUB(S); 

EXIT  ISTERM(TSUBST); 

BEGIN 

IF  (S=ZERO)  THEN  TSUBST^X 

ELSE  TSUBST:rSINGLETSU3ST(TSUBST(X,REST(S)),LAST(S)); 
END; 


FUNCTION  SINGLESUBST(L:TERMLIST;  S :S1NGL£SUB ):TERMLIST; 

ENTRY  I STERMLI ST (L ) a I SSINGLE SUB (S ); 

EXIT  ISTERMUST(SINGLESUBST); 

BEGIN 

IF  (L*ZERO)  THEN  SINGLESUBSf:*ZERO 

ELSE  SINGLESUBST:®CONS(SINGLETSUBST(HD(L),S),  SINGLESUBST(TL(L),S)) 
END; 


FUNCTION  SINGLETSUBST(T:TERM;  S:SINC  .ESUB):TERM; 

ENTRY  ISTERM(T)  a ISSINGLESUB(S); 

EXIT  ISTERM(SINGLETSUBST); 

BEGIN 

IF  ISVAR(T)  THEN  BEGIN  IF  (T=VAR(S1) 

THEN  SINGLETSUBST  ;»  TERM(S) 

ELSE  SINGLETSUBST  :»  T 
END 

ELSE  SINGLETSUBST  :»  MKTERM(FNLT(T),  SINGLESUBST(TERMS(T>,  S)> 
END; 


FUNCTION  COMP(S:SUO;  XtVAR;  Y:TERM);SUB; 

ENTRY  ISSUB(S)aISVAR(X)aISTERM(Y)a-OCCUR(X,Y); 
EXIT  I SS UB (COMP); 

BEGIN  COMP:»MKSUB(S,PAIR(X,Y));  END; 


Figure  10:  second  level  functions  and  goalfile 
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t Program  for  verifying 


ISSUB(SI)aISSINGLESUB(S2)aISTERMLIST(L) 

= [TSUBST(L,MKSUB(SI  ,S2))=SINGLETSUBST(TSU8ST(L.S I ) $2)1 
Program  body  of  TSUBST  with  new  entry/exil  eondilions  7. 


APPENDIX 


PASCAL 

ENTRY  ISSU8(S)a(S=MKSUB(SI  ,S2))aISTEPM(X); 

EXIT  {TSUDST=SINGLETSUBST(TSUBST(X,S  I ),S2)>; 

AXIOM  LAST(MKSUB(»9S,o$I  ))**S  1 ; 

AXIOM  REST(MKSUB(oStoSl))«Si 
AXIOM  (ZERO*MKSUB(»SI  ,«S2))«FALSE; 

BEGIN 

ENDS-ZER0>  THEN  TSUQST:'X  ELSE  TS^^ST:»SlNGLETSUBST(TSUBSr(X,REST(S)),LAST(S))} 


FOR  THE  MAIN  FKOGRAM  THERE  ARE  2 VERIFICATION  CONDITIONS 


• I 


(S«ZERO  ft  ISSUB(S)  ft  S=MK$UB(SI,S2)  ft  ISTERM(X) 
-*  X=SINGLETSUBST(TSUBST(X,S1  )tS2!) 


• 2 


<'S;ZER0  ft  ISSUB(S)  ft  S*MKSUB(SI,S2)  ft  ISTERM(X) 

SINGLETSUBST(TSUBST<X.REST(S}),LAST(S))«SINGIETSUBST(TSUBST{X,SI)PS2)) 

AFTER  SOME  SIMPLIFICATION,  YOU  CAN  GET 


• I TRUE 

• 2 TRUE 


Figure  II:  lemma  about  goal  15 
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GOALFILE 

7 Axiom?  defining  the  data  types  and  basic  (unctions  7 
7 I 7 AXIOM  ISTERMLIST (ZERO)  « TRUE; 

7 2 7 AXIOM  ISSUB(ZERO)»TRUE; 

7 Axioms  describing  properties  ol  sublundions  7 
7 3 7 AXIOM  APPEND  (ZERO,  raS)»S; 

7 4 7 AXIOM  APPEND(oS, ZEROES: 

7 5 7 AXIOM  APPENDfRCONStfJS.MDinTJJ.TKcD^APPENDISJ); 

7 6 7 AXIOM  IF  ISVAR(X)aISVAR(Y)a(Y/X)  THEN  >0CCUR(®X,®‘; /-TRUE* 
7 13  7 AXIOM  TSUBST(roX,ZERO)-X; 

7 14  7 AXIOM  IF  «'3VAR(X)  THEN  ~ISVAR(TSUBST(©X,®S))«TRUE; 


7 Goals  for  MGU  7 

7 26  7 GOAL  MGU(RCONM®X  I ,«s>X2),RCONS(©Y  I ,®Y2),  SC0MP(®S  I ,tt$2)) 

SUB  MGU(X  I ,Y  I ,S  I )aMGU(T$UI3ST(X2,S  1 ),TSUBST(Y2,SI  ),S2); 

7 27  7 GOAL  MGU(RCONS(®X I ,nX2),RCONS(<sY| ,qY2),  MKSU3(rSI,®S2)) 

SUB  MGU(X  I ,v|  ,S1  )aMGU(TSUQST(X2,S1  ),TSUBST(Y2,Si  ),S2); 

7 28  7 GOAL  MGU(RCONS(nX  1 ,®X2),RCON$(«Yl  ,oY2),®SI ) 

SUB  MGU(X  I ,Y  I ,SI  )a(TSUBST(X2,S1  )>TSUBST(Y2,SI )); 

7 29A  7 GOAL  MGU(mX,oY,PAIR(s>X1oY))  SUB  ISVAR(X)a1STERM(Y)a*OCCUR(X,Y); 

7 29B  7 GOAL  MGUtnX.nY.PAIRfnY.rcX))  SUB  ISVAR(Y)aISTERM(X)a-OCCUR(Y,X); 

7 30  7 GOAL  MGU(©XtaY,©S)  SUB  (FNLT(X)=FNLT(Y))aMGU(TERMS(X),TERMS(Y)1S); 

7 31  7 AXIOM  MGUfZERO.ZERO.ZEROWPUE; 

7 Goels  lor  NOTUNIF  7 

7 32  7 GOAL  NOTUNIF(®X.*)Y) 

SUB  ISVAR(X)aISTERM(V)a-ISVAR(Y)aOCCUR(X,Y), 

ISTERM(X)aISTERM(Y)a-ISVAR(X)a-ISVAR(Y)a  '(FNLT(X)«FNLT(Y))t 
(FNL  r(X)-FNLT(Y))ANOTUNir(TERMS(X),TERMS(Y)); 

7 33  7 GOAL  NOTUNIF(RCON$(s>x  I ,"'X2),RC0N$(nY  1 ,qY2)) 

SUB  MGU(XI,YI,®S)  a NOTUNIFlTSUGSTfXZ^Sl.TSUBSTfYS.BS)), 

MGU(X  I ,Y|  ,«aS)  a N0TUNIF(T$UBST(Y2,®S),TSUBST(X2,«$)) 

NOTUNIF  (X  2 , Y 2 ); 

7 34  7 GOAL  NOTUNIF(APPEND(®X I , siX2),A?PEND(®Yl,oY2)) 

SUB  (X2=ZER0)a-(Y2=ZER0)aMGU(X1,Y  1 ,®S), 

(Y2*ZER0)A'(X2=ZER0)aMGU(X  1 ,Y  1 ,®S), 

N0TUNIF(X1,Y1); 


A 


Figure  14  (continued) 
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APPENDIX 


PASCAL 

DEFFUN  HD(l:TERMLIST):TERM;  ENTRY  IST£RMUST(L)a~(L«ZERO);  EXIT  ISTERM(HD); 

DEFFUN  TL(L:TERMLIST):TERMLIST;  ENTRY  ISTERMLIST(L)a-(L=2ER0);  EXIT  ISTERMLIST(TL); 

DEFFUN  RCONS(l:TERMLIST;  X:TERM):TERMHST; 

ENTRY  ISTERWLIST(L)aISTERM(X);  EXIT  ISTERMLIST(RCONS); 

DEFFUN  TERMS (X:TERM):TERMLIST;  ENTRY  ISTERM(X)a-ISVAR(X);  EXIT  ISTERMLIST (TERMS); 

DEFFUN  FNLT (X:T£RM):CONST;  ENTRY  ISTERM(X)aMSVAR(X);  EXIT  ISCONST(FNLT); 

DEFFUN  T SUBS T(X:TERM;S:SUD): TERM;  ENTRY  I S TE RM(X )aISSUB (S);  EXIT  ISTERM(TSUBST); 

DEFFUN  MKSUB(S:SUB;  SI  :SINGLESUG):$UB; 

ENTRY  !SSUB(S)aISSINGLESUG(SI);  EXIT  ISSUB (MKSUB ); 

DEFFUN  PAIR(X:VAR;  Y;TERM):SINGLESUB; 

ENTRY  ISVAR(X)aISTERM^Y)a-OCCUR(X,Y);  EXIT  ISSINGLESUB(PAIR); 

DEFFUN  SCOMP(SI,S2:SUB):SJB;  ENTRY  ISSUB(SJ)aISSUB(S2);  EXIT  ISSUB(SCOMP); 

DEFFUN  OCCUR(X;VAR;  Y:TERM):BOOLEAN;  ENTRY  ISVAR(X)aISTERM(Y);  EXIT  ISBOOLEAN(OCCUR); 
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PROCEDURE  UNIFY(X,Y:TFRMLIST;  VAR  Z:SUB;  VAR  FLAG:INTEGER); 

ENTRY  ISTERMLIST(X)aISTEPMIIST(Y)  ; 

EXIT  (ISSUB(Z)  a MGU(X,Y,Z)  a (FLAG*!))  v ((FLAG=0)  a NOTUNIF(X,Y)); 
BEGIN 


t Initialization  ot  variable  * 

U:*ZERO:  Vi*ZERO;  Z;*ZERO;  XI:*X;  YI:*Y:  FLAG:*  l ; 

INVARIANT  (ISSUB(Z)aISTERMLISTIU)aISTFRMLIST(V)aISTERMLIST(XI) 

AlSTERMLIST(YI  )aMGU(U,V,:)a(x*APPEND(U.XI  ))a(Y*APPEND(V,YI  ))a  (FLAG* I )) 
v ((FLAG*0)aNOTUNIF(U.V)a(X.APPEN0(U,XI>)a(Y.APPEND(V,YI))) 


WHILE  (XI /ZERO)  a (Y I /ZERO)  a (FLAG*  I)  DO 
BEGIN 

X2:»  TSUBST(HD(XI),Z); 

Y2:«  TSUBST(HD(YI),Z): 

IF  ISVAR(X2)  THEN  BEGIN  IF  ISVAR(Y2) 

THEN  BEGIN 

END 

ELSE  BEGIN 
END 


IF  (X2/Y2) 

THEN  Z:*MKSUB(Z,PAIR(X2,Y2)) 

IF  OCCUR(X2,Y2)  THEN  FLAG:*0 
ELSE  Z:*MKSUB(Z,PAIR(X2,Y2)) 


END 

ELSE  BEGIN  IF  ISVARIY2) 

THEN  BEGIN  IF  OCCUR(Y2,X2)  THEN  FLAG  *0 
ELSL  Z:=MKSUB(Z,PAIR(Y2,X2)) 

END 

ELSE  BEGIN  IF  FNLT(X2)*FNLT(Y2) 

THEN  BEGIN  UNIFV(TERMS(X2),TERMS(Y2),Z2,FLAG)s 
IF  FLAG* I THEN  Z:*SC0MP(Z,Z2) 

ELSE  FLAG:*0 
END 

ELSE  FLAG:*0 

END 

END; 

U :*RCONS(U,HD(X  I )); 

V :*RCONS(V,HD(YI )); 

XI  :*TL(XI ); 

YI:*TL(YI)5 

END;  7.  End  oi  WH.tE  body  l 


IF  (XI /ZERO)  v (Y I /ZERO)  THEN  FLAG:*0 
END;  t Protoduro  body  7. 


THE  VERIFICATION  TAXES  2««  CPU  SEC 

Figure  M:  The  rnni|>lrie  program  and  documentation  for  UNIFY 


